View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001312JEDI VCL00 JVCL Componentspublic2004-01-29 04:512004-03-09 02:47
ReporteranonymousAssigned Touser72 
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0001312: Changed TJvFormPlacement behavior
DescriptionRestoreFormPlacement / SaveFormPlacement now only works if Active is set to True.
In previous versions they have worked independent of the Active-State.
This makes it easy possible to manually load settings in a certain order before the Forms are shown.
With the new behaviour we must set Active to True - RestoreFormPlacement and set Active to False (to avoid double loading!) before the OnShow event occur.
In my opinion the IsActive check should be replaced with AppStorage<>nil
-only inside RestoreFormPlacement / SaveFormPlacement.
I think I'm not the only one who uses TJvFormPlacement this way, and so other people will probably have the same problems...
If I have only simple Forms, I set Active to True and let the component do
the work automatically.
But with complex Forms -where the load/show order matters- I set Active to False and use RestorePlacement/SaveFormPlacement manually.

Here is the typically order with previcious version:
OnCreate
FormPlacement.Active:= False
RestoreFormPlacement
.....
OnDestroy
SaveFormPlacement
End

typically order with actual version:
OnCreate
FormPlacement.Active:= True (only works when active)
RestoreFormPlacement
FormPlacement.Active:= False ->to avoid double loading/saving
.....
OnDestroy
FormPlacement.Active:= True (only works when active)
SaveFormPlacement
End

The actual behaviour has disadvantages
1. additional Active-State changes
2. breaks existing code

-but I can't see any advantages, so why not change back to the old
behaviour?

Maybe it's possible to let the programmer decide when
RestoreFormPlacement / SaveFormPlacement events should occur,
for example:
RestoreEvents:TStorageEvents
-OnCreate:boolean
-OnShow:boolean (default)

SaveEvents:TStorageEvents
-OnClose:boolean (default)
-OnDestroy:boolean

With the default setting the behavior is still the same
as in previous versions.

(Se also my post in jedi.vcl Newsgroup from 06.01.2004
Subject:Changed TJvFormPlacement behavior)

Greetings
Ingo
TagsNo tags attached.

Activities

user72

2004-01-29 10:11

  ~0002868

Agree, this should be changed back to the old behavior if possible

user72

2004-01-29 15:57

  ~0002881

This is being discussed in the newsgroup as well. Should we take it there for the time being and post a summary here once we have a solution?

Ingo

2004-01-29 16:42

reporter   ~0002883

>>This is being discussed in the newsgroup as well
Yes, I have startet the thread.

>>Should we take it there for the time being and post a summary here once we have a solution?

Why? Maybe someone who only reads the news have another idea.

Greetings
Ingo

user72

2004-01-30 00:58

  ~0002892

I've updated JvFormStorage so you should now be able to call SaveFormPlacement and RestoreFormPlacement regardless of Active.

This update also affects 0001304

Ingo

2004-02-01 15:41

reporter   ~0002922

There are still problems, please see my feedback at:
TJvFormStorage/TJvAppIniFileStorage delete Sections/Bug ID:0001304
There is also the OldIni test project.

What do you think about the feature mentioned in the first message:
>>Maybe it's possible to let the programmer decide when
>>RestoreFormPlacement / SaveFormPlacement events should occur

Setting the events to OnCreate/OnDestroy has the advantage
the events occur only once (without manual calls to
RestoreFormPlacement/SaveFormPlacement) and not every time
the corrersponding form is shown or hidden.

Greetings
Ingo

user72

2004-02-02 11:02

  ~0002923

>What do you think about the feature mentioned in the first message:
That might be possible but at the moment we have a code freeze which means we cannot add features. I'll keep it for later.

user72

2004-02-13 14:08

  ~0002936

Seems to be working now, so closing

Issue History

Date Modified Username Field Change
2004-01-29 04:51 anonymous New Issue
2004-01-29 10:11 user72 Note Added: 0002868
2004-01-29 15:57 user72 Note Added: 0002881
2004-01-29 15:57 user72 Assigned To => user72
2004-01-29 15:57 user72 Status new => confirmed
2004-01-29 16:42 Ingo Note Added: 0002883
2004-01-30 00:58 user72 Note Added: 0002892
2004-02-01 14:39 user72 Status confirmed => feedback
2004-02-01 15:41 Ingo Note Added: 0002922
2004-02-02 11:02 user72 Note Added: 0002923
2004-02-13 14:08 user72 Status feedback => resolved
2004-02-13 14:08 user72 Resolution open => fixed
2004-02-13 14:08 user72 Note Added: 0002936
2004-03-09 02:47 user72 Status resolved => closed