If you issue oDlg:End() then you will have to recreate the DIALOG (DEFINE DIALOG etc.) again. You can't reuse an ended DIALOG.
EMG
Bitmaped and transparent dialogs
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- don lowenstein
- Posts: 196
- Joined: Mon Oct 17, 2005 9:09 pm
- Contact:
I have done this in the past. Each control needed to be "refreshed" in the initialization of the ::activate()
The reason I did this was due to many controls / folder pages, etc, which were created from data driven applications. The computers were much slower ( 386 speed ) and this saved lots of overhead.
Upon 're-activation' the controls worked fine, but, my dialog's background was "transparent".
Not an issue anymore - computers are much faster and no problem saving data-driven parms in an array and define / activate each time needed.
Things have come a long way, haven't they?
The reason I did this was due to many controls / folder pages, etc, which were created from data driven applications. The computers were much slower ( 386 speed ) and this saved lots of overhead.
Upon 're-activation' the controls worked fine, but, my dialog's background was "transparent".
Not an issue anymore - computers are much faster and no problem saving data-driven parms in an array and define / activate each time needed.
Things have come a long way, haven't they?
Don Lowenstein
www.laapc.com
www.laapc.com
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
- don lowenstein
- Posts: 196
- Joined: Mon Oct 17, 2005 9:09 pm
- Contact:
Exactly -
For me, easier to store dialog parms in a database and build dynamically vs. create resource, manually code controls to variables. etc. Using a data dictionary for me, is cleaner - only one input program, only one browse/update program, etc.
For me, easier to store dialog parms in a database and build dynamically vs. create resource, manually code controls to variables. etc. Using a data dictionary for me, is cleaner - only one input program, only one browse/update program, etc.
Don Lowenstein
www.laapc.com
www.laapc.com
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
It is still not correct. Ending a dialog means that the DialogBox Windows object is released and you can't use its handle anymore. If you want to use the dialog again you have to instantiate a new TDialog object.James Bott wrote:Enrico,
I agree, but I think he is just saying that he is storing the parameters in an array, then reusing the parameters to define and acitvate the dialog each time. I guess this would be no different than rereading them from a resource file.
Don, am I right?
James
EMG
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Are you saying that you issued DEFINE DIALOG etc. again with the same parameter of the first one? If yes then it's ok to do so. What you can't do is to end a dialog and then activate it again without defining it.don lowenstein wrote:Exactly -
For me, easier to store dialog parms in a database and build dynamically vs. create resource, manually code controls to variables. etc. Using a data dictionary for me, is cleaner - only one input program, only one browse/update program, etc.
Regarding your main problem, try to build a reduced and self-contained sample.
EMG