Hi,
Is there any documented list of statements/attributes/methods that cause a frame to get realized?
I'm currently trying to embedded a legacy frame in a .NET WindowContainer but to be able to do that, the frame must not be realized yet.
Since a lot of legacy code is being applied to the frame, I can't quickly see what exact statement is causing the realization...
I know making the frame visible causes realization, but what other statements should I consider as possible culprit?
You may be able to figure out what's causing the frame to be realized by setting a watchpoint in the debugger on the HWND of a widget in the frame. I tested this with a simple program.
DEFINE VARIABLE a AS CHARACTER NO-UNDO.
DEFINE VARIABLE b AS CHARACTER NO-UNDO.
DEF FRAME f a b.
ENABLE a b WITH FRAME f.
BELL.
BELL.
WAIT-FOR GO OF FRAME f.
I started the program in the debugger and set a watchpoint on a:HWND. Then I continued execution. The debugger stopped on the first BELL statement, indicating that the ENABLE statement caused a to be realized.
You can't test the frame's HWND this way because there appears to be a bug in watchpoints which doesn't allow an expression like "FRAME f:HWND".
we had problems when there was an image on the title bar
Note, you don't embed frames. You embed windows.
LOAD-ICON is causing the Window to be realized.
Hi Mike
Correct, but in our case the Frames get a classic dummy Window wrapped around them just before putting them in a WindowContainer (the legacy application used to have a single main Window, with inside only Frames, no other Windows).
So we're sure it is something related to the Frame and not the Window that is causing realization...
There is no LOAD-ICON or Image...
You may be able to figure out what's causing the frame to be realized by setting a watchpoint in the debugger on the HWND of a widget in the frame. I tested this with a simple program.
DEFINE VARIABLE a AS CHARACTER NO-UNDO.
DEFINE VARIABLE b AS CHARACTER NO-UNDO.
DEF FRAME f a b.
ENABLE a b WITH FRAME f.
BELL.
BELL.
WAIT-FOR GO OF FRAME f.
I started the program in the debugger and set a watchpoint on a:HWND. Then I continued execution. The debugger stopped on the first BELL statement, indicating that the ENABLE statement caused a to be realized.
You can't test the frame's HWND this way because there appears to be a bug in watchpoints which doesn't allow an expression like "FRAME f:HWND".
Thanks Matt, I'm looking into that right now...
It appears querying the Y property of a classic COMBO-BOX triggers its realization...
Any way to prevent this?
I think that the only way to avoid realization in that case is to not query the Y property until after the point where you explicitly realize the frame. Querying any of the position or size attributes will force realization of the frame. It has always been this way, but I'm not sure what the reasoning was.
It appears not all widgets exhibit this behavior. Querying of those properties on simple FILL-INs is no problem.
In my case a legacy routine tries to optimally resize the frame according to its contents (kinda like the AutoSize functionality on a .NET container).
Guess some creativity will be needed here...