Drawing from code originally supplied by Carlo Pagani and Chris Boss I developed routines which will allow a user to move and resize any window and save those settings. The next time that window is opened the saved settings are applied.
It does not seem to be an issue with secondary windows but when the program first starts there is a flicker from when the startup window first opens as it moves from its original screen position to the one last used by the user.
I have the resize/move action being called from FORM1_WM_CREATE but I have tried from several other areas all with the same result.
I tried setting the WindowStyle WS_VISIBLE to false and then using FF_CONTROL_SHOWSTATE at the end of FORM1_WM_CREATE but I ended up getting a flicker and then the window going back to its non-visible state.
I also toyed with the idea of injecting my coordinates into the CreateWindowEx routine creating the window but I have no idea where or how I might do something like that. Setting the StartupPosition property to Manual just seems to set FF_nLeft and FF_nTop to zero but I do not seem to be able to access them.
Could you suggest where and how I might control this?
thanks
David
Hi David,
I would like to see the code that you are using in the WM_CREATE handler because I added the simple function call below and I got no flicker (well, no flicker that I could notice on my laptop):
SetWindowPos hWndForm, 0, 10, 10, 0, 0, %SWP_NOSIZE
The above simply moves the form to screen coordinates 10, 10.
Maybe you are using multiple calls to the MoveWindow function. I find that the SetWindowPos function works really well.
Anybody else notice flicker on the initial setting of the window position ???
As the window isn't show yet in WM_CREATE it sounds like either how you move it is causing it to be shown or it is firing a message that is being caught by a WM_SIZE or something and making things show wrong for the flicker.
Roger, you pointed me in the right direction.
I did not realize WM_SIZE was called before WM_CREATE. As a result all of my resize/move code was being called one more time and sooner than I was expecting it to be.
Everything seems to be working as expected now.
thanks
Yup, I had the same problem before...along with various other painting issues that I ended up switching to DeferWindowPos to handle.
Yeah, been there many tmes...
Some thoughts:
Sub FF_Control_Hide (ByVal hWndControl As Dword)
Now - I'm sure we've all made our own routines to handle this with various API Calls - and (Tricks). And I'm sure there are at least several variations from one source to the next.
I could go on... but to keep this short - there are a few other possible routines (like the above) - that would make all of our lives much easier.
If you are going to have: Sub FF_Control_Disable (ByVal hWndControl As Dword) - then why NOT - add the rest of these logical functions? I guess what may seem logical to me - is not logical at all.
Mike
I opted to use FF_CONTROL_SHOWSTATE to handle hiding a form/control because it allows for one function that can process many different states. I guess that a separate function could have been created specifically for a Hide.
FF_CONTROL_SHOWSTATE hWndForm, %SW_HIDE
Hi,
FF_CONTROL_SHOWSTATE hWndForm, %SW_HIDE
Completely - overlooked this one! It may be the answer I have been looking for - and I can replace many routines - with a single line!
Thanks
Mike