MDI arrangment commands reversed?

maker · Post by **maker** » Sat Apr 11, 2009 8:02 pm

Has anyone else noticed MDI arrangement commands giving the reverse effect of what one would expect?

e.g.
In my test app:

Code: Select all

SetGadgetState(mdinum, #PB_MDI_Next)
;shifts focus to the mdi window that was the previously focused mdi window

SetGadgetState(mdinum, #PB_MDI_Previous)
;shifts focus to the mdi window that what was *not* previously focused

SetGadgetState(mdinum,  #PB_MDI_TileHorizontally)
;tiles the windows so their longest dimension is vertical

SetGadgetState(mdinum,  #PB_MDI_TileVertically)
;tiles the windows so their longest dimension is horizontal

Also, the horizontal and vertical tilings shift over to what is often referred to as 'Arrange' behaviour once the window count gets high enough.

All of these behaviours are exactly opposite what I think of as the standard behaviour (based on my experience in an MS Windows evironment with many different apps I've used over the last 15 years or so).

Is this something from the Amiga/Linux/Mac worlds? Or a bug? Or something else, Euro preferences versus USA preferences, maybe?

Please note, I realize these things are subject to variation; I have seen some variation in apps handling of mdi over the years. However, most of the apps I have used did things backwards from the way PB is handling it. I don't really have any objection to it, as I have written macros to make them work the way I expect, I'm just curious whether this was intentional or an accident.

Fluid Byte · Post by **Fluid Byte** » Sat Apr 11, 2009 9:26 pm

I guess the problem sits in front of the computer ...

Can't confirm any of the behavior you mention here. As for previous/next commands; make sure the windows are sorted in creation order!

This works without any problem:

Code: Select all

Enumeration
	#WIN_Main
	#WIN_MDIChild1
	#WIN_MDIChild2
	#WIN_MDIChild3
	#WIN_ToolWindow1
	#WIN_ToolWindow2
EndEnumeration

Enumeration
    #IDM_New
    #IDM_Open
    #IDM_Save
    #IDM_SaveAs
    #IDM_Exit
    #IDM_Undo
    #IDM_Cut
    #IDM_Copy
    #IDM_Paste    
    #IDM_Cascade
	#IDM_TileHorz
	#IDM_TileVert
	#IDM_Next
	#IDM_Previous
	#IDM_Arrange 
	#IDM_About	
EndEnumeration

#IDM_FirstChild = #PB_Compiler_EnumerationValue

UseJPEGImageDecoder()

OpenWindow(#WIN_Main,0,0,800,600,"void",#WS_OVERLAPPEDWINDOW | 1)

CreateMenu(0,WindowID(#WIN_Main))
MenuTitle("&File")
MenuItem(#IDM_New,"&New..." + Chr(9) + "Ctrl+N")
MenuItem(#IDM_Open,"&Open..." + Chr(9) + "Ctrl+O")
MenuItem(#IDM_Save,"&Save" + Chr(9) + "Ctrl+S")
MenuItem(#IDM_SaveAs,"Save &As...")
MenuBar()
MenuItem(#IDM_Exit,"E&xit" + Chr(9) + "Alt+F4")
MenuTitle("&Edit")
MenuItem(#IDM_Undo,"&Undo" + Chr(9) + "Ctrl+Z")
MenuBar()
MenuItem(#IDM_Cut,"Cu&t" + Chr(9) + "Ctrl+X")
MenuItem(#IDM_Copy,"&Copy" + Chr(9) + "Ctrl+C")
MenuItem(#IDM_Paste,"&Paste" + Chr(9) + "Ctrl+V")
MenuTitle("&Window")
MenuItem(#IDM_Cascade,"Cascade")
MenuItem(#IDM_TileHorz,"Tile Horizontally")
MenuItem(#IDM_TileVert,"Tile Vertically")
MenuItem(#IDM_Next,"Next")
MenuItem(#IDM_Previous,"Previous")
MenuItem(#IDM_Arrange,"Arrange")
MenuTitle("&Help")
MenuItem(#IDM_About,"About ...")

MDIGadget(0,0,0,0,0,2,#IDM_FirstChild,#PB_MDI_AutoSize)

SetGadgetAttribute(0,#PB_MDI_Image,LoadImage(0,#PB_Compiler_Home + "Examples\Sources\Data\terrain_texture.jpg"))

AddGadgetItem(0,#WIN_MDIChild1,"MDI Child Window #1")
AddGadgetItem(0,#WIN_MDIChild2,"MDI Child Window #2")
AddGadgetItem(0,#WIN_MDIChild3,"MDI Child Window #3")

Repeat
	EventID = WaitWindowEvent()

	If EventID = #PB_Event_Menu
		Select EventMenu()
			Case #IDM_Cascade : SetGadgetState(0,#PB_MDI_Cascade)
			Case #IDM_TileHorz : SetGadgetState(0,#PB_MDI_TileHorizontally)
			Case #IDM_TileVert : SetGadgetState(0,#PB_MDI_TileVertically)
			Case #IDM_Next : SetGadgetState(0,#PB_MDI_Next)
			Case #IDM_Previous: SetGadgetState(0,#PB_MDI_Previous)
			Case #IDM_Arrange : SetGadgetState(0,#PB_MDI_Arrange)
		EndSelect
	EndIf
	
Until EventID = #PB_Event_CloseWindow

maker · Post by **maker** » Sat Apr 11, 2009 10:06 pm

Fluid Byte wrote:I guess the problem sits in front of the computer ...

Yes, partly

The tile vertical/horizontal does okay with your 3 window sample, so I probably had something backwards in my original code (but see later in this post for what happens if you add more windows).

However, next/prev is still backwards.

As for previous/next commands; make sure the windows are sorted in creation order!

This works without any problem:

Not true, it is still backwards on next/prev behavior. Immediately after running the code, window creation order is 1,2,3. SO:

MDI Child Window #3 is active.

Clicking Window->Next should activate MDI Child Window #1

It does not; it activates MDI Child Window #2

Likewise, run the prog again:

Clicking Window->Previous should activate MDI Child Window #2

It does not; it activates MDI Child Window #1

So, a reversal in my original code accounts for the backwards tiling, but the rest of my original post still stands: PBs MDI does not match the behavior I am used to.

A recap of the behavior that suprises me:
next acts like previous
previous acts like next
tile horizontal/vertical start acting different with larger numbers of windows
(I am used to tile vert, for example, creating windows that are the same height as the client area with width changed to make them all fit if possible, and if not possible then it should *still* create windows the same height as the client area, they just spill over out of sight into the scrollable area of the mdi)

Post by **freak** » Sat Apr 11, 2009 10:37 pm

SetGadgetState(#Gadget, #PB_MDI_Next) just causes a WM_MDINEXT message to be sent with both parameters being 0. According to the documentation, that activates the next window ( http://msdn.microsoft.com/en-us/library/ms644918.aspx ). The same goes for the other flags. They just map to SendMessage() calls.

Now, if your definition of "next window" differs from that of Microsoft, then take it up with them

maker · Post by **maker** » Sun Apr 12, 2009 1:21 am

freak wrote:
Now, if your definition of "next window" differs from that of Microsoft, then take it up with them

Cute. :roll:

Anyway, I guess I just got lucky (or unlucky, if you like) in my choice of programs in the past. Apparently their authors considered the MS definition of next to be backwards (as do I) and reversed it to suit themselves (as will I).

Just to clarify: I freely acknowledge that PBs MDI arrangements send the correct messages according to MicroSoft documentation and that this is not a bug. I just happen to think the Microsoft interpretation is wrong