Info Only Update 08-13-2012

[LarryMc]

Completed a rewrite of how the sizing of the IDE's main, project and output windows works.
what I had before was:
When either(or both) the Project or Output windows are open they are docked to the Main IDE window.

The Project window is docked to either the left or right side of the Main window.
Its height is automatically set to the height of the Main window and the width is user adjustable.
If the Main's height is changed the Project's height tracks it.

The Output window is docked to either the top or bottom side of the Main window.
Its width is automatically set to the width of the Main window and the height is user adjustable.
If the Main's width is changed the Output's width tracks it.

All pretty straight forward and relatively easy to code.

If left like that everything works fine until you make the Main window too large; either by dragging to change its size or maximizing the Main window.
Doing this would result in the Project and/or Output window(s) being out of view.

So I had added code that used GETSCREENSIZE to determine the size of the user's screen.  Then I checked to see if the Project's width(if open) plus the Main's width was equal to or greater than the screen width.  If it was then I reduced the width of the Main.  I did the same sort of thing with the height of the Output window.  Again, not really that hard.
But there were a lot of @IDSIZE,@IDMOVE messages floating around because if I resized the Main it would cause the Project/Output windows to change size which in turn would require recalc of the Main window.

I thought I had it all working fine and submitted it to Bruce(beta tester).

His complaint was that if he maximized the Main window it worked fine for the project window but he could see the output window.
You would think that a flaw that blatant would be easy for me to see. NOT!

Bruce sent me a screenshot to 'prove' he was stating what he was seeing correctly.
I didn't notice at the time but discovered several desparate hours later that the OS task bar was visible in his screen shot.
On my computer I could never take a picture of a maximized window and have the task bar showing.  That's because when my mouse moves out of that area of the screen the task bar slides out of view.

Searching the MS help I found that there is a "auto-hide" feature of the task bar. You can see it if you right-click in the taskbar and select the properties option.  Bruce didn't have that option selected on his computer therefore his taskbar is always visible.
While in that properties dialog I also noticed that there was a taskbar "locked" option. If selected it prevents the user from moving the taskbar to one of the other edges of the screen.

If the task bar is visible and a window is maximized the OS automatically adjust for the presence of the taskbar and sizes the window to something less than the screen size. That meant that my size test was always failing.

So I now knew how to duplicate his problem. I also knew that I have to account for the presence/absence of the task bar, the location of the taskbar (bottom,left,top,right) and the size of the task bar (it IS adjustable).

I started with the GETSCREENSIZE command to get the width and height of the screen.
The values returned are like hardware values and totally ignore anything displayed on the screen.
So with that I know the the max size I can possibly have.
To get the info I need to know about the taskbar I ran across the SHAppBarMessage API.
With this message:

Code Select Expand

int stat = SHAppBarMessage(ABM_GETSTATE,pdata)I could determine whether or not the taskbar was visible.
With this message:

Code Select Expand

SHAppBarMessage(ABM_GETTASKBARPOS,pdata)
I could determine the location and size of the taskbar.
Using that info I determined fudge factors to apply to the resizing of the Main window.

So, I had code in place that when the main menu is maximized(size determined by the OS), I would resized it as necessary and also adjust the Project and Output windows as required.

Didn't work at all like expected. I was trying to resize all three windows inside the Main's @IDSIZE handler.  It apeared that all the events were out of sync on the timing of internal messages.  I say that because all my calculations were correct.
I was using the MOVEWINDOW api to move/resize each of the windows.
And remember that when the Main window changes size it causes the Project and Output windows to change sizes which in turn can cause the Main window to change sizes and round-and-round we go.

If there was some way I could make all changes to the 3 windows at one instant before all the messages start flying I would have it made.
Well, you can!

This pseudo code does just that:

Code Select Expand

int wpi=BeginDeferWindowPos(3)
DeferWindowPos(wpi,main.hwnd,0,l1,t1,w1,h1,SWP_NOACTIVATE|SWP_NOZORDER)
DeferWindowPos(wpi,output.hwnd,0,l2,t2,w2,h2,SWP_NOACTIVATE|SWP_NOZORDER)
DeferWindowPos(wpi,project.hwnd,0,l3,t3,w3,h4,SWP_NOACTIVATE|SWP_NOZORDER)
EndDeferWindowPos(wpi)

Now appears that all is well in the world.(I'll find out for sure after Bruce looks at it.)

I know this was sort of long winded but I thought it was a significant learning opportunity. It was for me.

[ZeroDog]

You may want to have a look at the following tutorial:

http://www.ionicwind.com/forums/index.php?topic=5030.0

It shows how to properly limit the minimum and maximum extents that the window can be resized, and shows how to properly adjust the window size when the window is maximized (for example, to ensure that when the main window is maximized, the output and project windows still have room to be displayed beside the main window).


Also, you should not be using the GetScreenSize to determine anything but the screen size.  You should not be using it to determine how big to size a window, as you found out, tasksbars cause issues this way.

You should be able to use the GetSystemMetrics API to determine what size to make a maximized window based on the size of the taskbar.

You should be able to figure out which GetSystemMetrics flag to use from this project. 

http://www.ionicwind.com/forums/index.php?action=dlattach;topic=4204.0;attach=3431 

[LarryMc]

You may want to have a look at the following tutorial:

http://www.ionicwind.com/forums/index.php?topic=5030.0

It shows how to properly limit the minimum and maximum extents that the window can be resized, and shows how to properly adjust the window size when the window is maximized (for example, to ensure that when the main window is maximized, the output and project windows still have room to be displayed beside the main window).

I had found that after I was real deep into what I was doing.
I wish I had found that earlier.  It would have been a real easy way for me to limit the size than the way I wound up with.
I believe it would have eliminated a lot of my sync issues and would have also eliminated one of my movewindow commands.
However, your program, as it is currently written, doesn't take into consideration the taskbar even exists.  But I know you know that.

Also, you should not be using the GetScreenSize to determine anything but the screen size.  You should not be using it to determine how big to size a window, as you found out, tasksbars cause issues this way.

You're preaching to the choir now.

You should be able to use the GetSystemMetrics API to determine what size to make a maximized window based on the size of the taskbar.

You should be able to but you can't.
In the SDK section on GetSystemMetrics it says:

To get the coordinates of the portion of the screen not obscured by the system taskbar or by application desktop toolbars, call the SystemParametersInfo function with the SPI_GETWORKAREA value.

[/quote]
This returns a winrect  and the .top and .left that indicate where the upper left corner of a maximized window.
All four values have already taken into consideration the location and size of the task bar.

I could have replaced the use of the SHAppBarMessage api with the SystemParametersInfo api.

So, we have learned  or reinforced the following.

1. I'm an amature hobby programmer which I have admited numerous times.
2. Almost without fail, there is always more than one way to accomplish a task.
3. The older I get the harder it is for me to remember stuff; even from the day before in some cases.
4. It's just pure stubborness that keeps me plugging along.

Since I still have my test program I might go back and revise it to see if I can replace the following with 2 movewindow commands

Code Select Expand

int wpi=BeginDeferWindowPos(3)
DeferWindowPos(wpi,main.hwnd,0,l1,t1,w1,h1,SWP_NOACTIVATE|SWP_NOZORDER)
DeferWindowPos(wpi,output.hwnd,0,l2,t2,w2,h2,SWP_NOACTIVATE|SWP_NOZORDER)
DeferWindowPos(wpi,project.hwnd,0,l3,t3,w3,h4,SWP_NOACTIVATE|SWP_NOZORDER)
EndDeferWindowPos(wpi)

If I do and the code is cleaner and easier to use I'll let ya'll know.

[ZeroDog]

"I'm an amature hobby programmer which I have admited numerous times."

Don't sell yourself short, you've taught many people many things.


"The older I get the harder it is for me to remember stuff; even from the day before in some cases."

Being a programmer isn't about knowing or remembering everything, its about knowing how to find the answers when you don't already know them.

Oh, and not remembering everything I've learned is one of the reasons I make code snippet samples that I can look back upon when I need to.

[LarryMc]

Oh, and not remembering everything I've learned is one of the reasons I make code snippet samples that I can look back upon when I need to.

But I forget that I made them and sometimes where I put them. 

Being a programmer isn't about knowing or remembering everything, its about knowing how to find the answers when you don't already know them.

And I'm beginning to forget where to find the answers.

Anyway, since my last post I did rework the sizing stuff.
The code starts off with

Code Select Expand

winrect wr
getscreensize oscreenw,oscreenh
SystemParametersInfo(SPI_GETWORKAREA,0,wr,0)
int screenwidth=wr.right-wr.left
int screenheight= wr.bottom-wr.top
getsize g_project,l3,t3,w3,h3
getsize g_output,l5,t5,w5,h5
GETSIZE g_main,l2,t2,w2,h2
followed by nested if statements with 3 clusters of

Code Select Expand

*<MINMAXINFO>@lparam.ptMaxSize.x =...
*<MINMAXINFO>@lparam.ptMaxTrackSize.x =...
*<MINMAXINFO>@lparam.ptMaxPosition.x = ...
and 3 clusters for y
and (drum roll).......
I DELETED ALL THOSE API CALLS I SO CAREFULLY DESCRIBED ABOVE!!!!!
And it made everything smoother; less IDSIZE's being sent around.

In 6 months I'll be able to look at this code and understand what I did; I'm not so sure about my previous code.

[LarryMc]

Good thing I went ahead and changed this code.
I was trying something with the old version and discovered a bug
If I maximized the window By dragging in either direction it kicked my old code in
Once the code was activated if you tried to drag one edge of the main window to make it smaller it wouldn't change.
You'd have to be be able to reduce the width and height at the same time to be able to make it reduce.

Your 1st instinct would be to click the max/min button but since windows considered it in the normal state it would put it in the maximized state.
If you clicked it again to go back to normal it would stay the same size because that's the way it was when you hit maximize.
To get out of it you would have to close both the project and output windows and then drag the main window to reduce its size.

The new version of the code clears all of that up..

I had previously said there are more than one way to accomplish a task.
I'll eat crow and say that this time there appears to be only one way to do it correctly.

[ZeroDog]

But I forget that I made them and sometimes where I put them. 

  Your're not alone with that.  I don't know how many times I've spent a long while looking for a sample that I think I made, but I don't remember what I called it, or where I put it, but I'm sure that I made it.  And then after I end up working it all out and make a new sample, I end up saving it in almost the exact same place as the first sample.   

less IDSIZE's being sent around.

Yeah, I hate when you end up with code that is firing off too many messages.

Sometimes I'll throw a messagebox into various parts of window process handler subroutines to see how many times a window is recieving a certain message, and sometimes I'm astounded how many times the window is being sent the message.

For example, on startup, sometimes I'll notice that my window ends up being sent numerous IDSIZE messages when it's creating and setting up the window, so what I will sometimes do is set a variable (Loading=1) and in the message handler I will have a conditional that will only process the message once the window is finished being setup (Loading=0).  It usually results in a smoother startup with less flickering.

I did notice some flickering and it seemed like your windows were redrawing things too many times when it wasn't needed in the previous beta of IWB3 that you posted, such as when you click on the right side of the tab control, where there is not tab.

I've been hoping for another beta release to see if these issues have been resolved yet, but I can be patient. 




Is it ready now?   

[LarryMc]

I've been hoping for another beta release to see if these issues have been resolved yet, but I can be patient. 

There's not going to be another "freebie-to-the-world" beta update because it is now capable of compiling programs.

As to all that flickering in the last beta release.
In the current version that is being beta tested all of that is gone.
It looks like you would expect  it to look.