im trying to build a main window from which multiple secondary windows can be created [mathsproc and its child window paramproc being the createwindowex procedures] ive attached the source rc and exe but i dont think im doing this correctly as
1) when i create a second instance of the maths window by clicking on new in the main window menu ... firstly i get no response then the second window is generated on a second click .. its as if im in the wrong proc [maths and not main ....except im not ]
2) when i delete a second instance of the maths window i then loose the ability to control the first instance [ this may be thread related ???? but i expect some of you prob know much more precisely whats going on in windows and can explain it thoroughly to me as i bet im not the only person who has ad issues like this
3) the z-order seems to be odd prob due to creating so called child wndows which arent regarded as children ??? athough i do like the ability to right click on the windows [ this is with maths window and or added param window and sort of toggle through them ]
all help and advice gratefully received .. many thanks mike b
In MathProc, instead of hwndMaths you should use hMaths, since whenever you create again with an IDM_NEW, your WndProc overwrites the previous hwndMaths. Perhaps also try WS_CLIPSIBLINGS.
You have a few options with child windows, create all of them and show or hide them on a needs basis. You can put child windows in a DLL and load or unload them as well. If you use the main window as the parent window, all child windows will display above it which means the parent window is always below the child in Z order terms.
Try looking up Multiple Document Interface in the win32.hlp file. The function CreateMdiWindow. Radasm3 sourcecode is an example of a MDI.
The functionality you're trying to re-create is already provided by windows, as already mentioned this is called a "Multiple Document Interface (MDI)"; this gives you support for handling the child windows inside another 'parent' along with support for switching between them, tiling, cascading, etc.
The top level documentation is here: https://docs.microsoft.com/en-us/windows/desktop/winmsg/multiple-document-interface (https://docs.microsoft.com/en-us/windows/desktop/winmsg/multiple-document-interface)
and a detailed explanation to get you started: https://docs.microsoft.com/en-us/windows/desktop/winmsg/using-the-multiple-document-interface (https://docs.microsoft.com/en-us/windows/desktop/winmsg/using-the-multiple-document-interface)
thanks for all your kind replies .. ive got it all working now and made a lot of stupid dropoffs plus Windows does some very silly things as explained below
1) thanks Hutch.. i have used the show/hide mechanism before ad this was nice and easy .. i like the idea of using DLLs as i hope im correct in saying that with a DLL you also get the benefit of 2gig space in each as its a separate process ??? [and the output from the maths stuff can be large even compressed as they are in my programs ]
2) Tedd im trying to use menus and i dont think you can get these on child windows ??
3) here are the things i found ... firstly windows seems to imply have to specify a different class to get your lower level windows to work independantly ..
oddly although it requires a different proc in WNDCLASSEX it uses the proc of the first window you specify .. the good news is that by putting a simple test for the handle at the beginning of {normally} WndProc or similar you can send the messages to the appropriate handling section .. secondly the mistake i made was thinking that the first window owned the second an was ties by instantiation to it .. the create window should have the usual 0,menu,hInstance in it after the co-ordinates .. also crucially the class must be the same in WNDCLASSEX as on CreateWindow [seems to be a well known fact i got wrong ]
many thanks for the advice .. regards mike b
Tedd ..because i want to vary the ability of the program so it can "restructure itself depending on the process" [ie if i want to have 3 input boxes instead of 4 and two output listboxes for comparison] i read in a CSV style file initially into the program giving the placement and type of edit boxes /list boxes/combo boxes/buttons etc that i want on each window .. because these are held in separate heaps it means that if i want to destroy and recreate the window in a different form then i can .. i think dialog boxes and mdi windows might be a bit restrictive anyway this is all programed and was surprisingly easy to do [compared to the stupid MS window stuff] ..
the heaps for each window contain some information about theselves eg window handles id and placement but i now have the much more tricky problem of associating them with a process so for example if i want to add two number together i have to link the button/menu/mouse option in XXXproc that processes the window with say an add DLL .. unfortunately i decided the CSV file could come in in a fairly random order so i prob now have to have a window with [a many to many link] to a process table ??? .
The idea is eventually to end up with something that looks a bit like a flowchart with boxes containing processes and links
regards mike b
Quote from: mikeburr on June 13, 2019, 07:38:18 AM
1) thanks Hutch.. i have used the show/hide mechanism before ad this was nice and easy .. i like the idea of using DLLs as i hope im correct in saying that with a DLL you also get the benefit of 2gig space in each as its a separate process ??? [and the output from the maths stuff can be large even compressed as they are in my programs ]
DLLs are loaded into your address space - they don't magically give you an extra 2 GiB to play with; you would need to explicitly create separate processes to get this, but you'd generally be better using views into memory mapped files if you need to support huge structures.
Quote
2) Tedd im trying to use menus and i dont think you can get these on child windows ??
The child windows don't get their own menus, but you can dynamically modify the parent's menu according to which child is currently in focus (there would only be one menu - on the parent window - but it would change to match which child you're using).
Quote
3) here are the things i found ... firstly windows seems to imply have to specify a different class to get your lower level windows to work independantly ..
Yes, child windows are not parent windows, so they need a different class (they can also each have a different class from each other, so each child acts differently).
Quote
oddly although it requires a different proc in WNDCLASSEX it uses the proc of the first window you specify
Not quite; the parent receives all messages for its children so it can choose to pass them on or filter them out, and possibly do something according to the message.
Quote
secondly the mistake i made was thinking that the first window owned the second an was ties by instantiation to it .. the create window should have the usual 0,menu,hInstance in it after the co-ordinates .. also crucially the class must be the same in WNDCLASSEX as on CreateWindow [seems to be a well known fact i got wrong ]
If you create separate windows then they are treated as separate windows, even if they're created in the same process. If you create additional windows as children of another, they're still essentially separate unless the parent explicitly does something to modify their behaviour (this is why the parent receives its children's messages.)
CreateWindow creates a window of the class it's asked to, so of course this must match the name of a registered window class.
Having a good explore of the normal style and extended styles of a window created with CreateWindowEx() is very useful and it gives you very good adjustment of the windows you want to create. Windows like normal controls are generally captive within the interface of the parent but you can create windows that remain above the parent in terms of Z order that are not constrained by the parent interface. Dialogs are a good example of this.
Quote from: mikeburr on June 13, 2019, 07:55:52 AM
Tedd ..because i want to vary the ability of the program so it can "restructure itself depending on the process" [ie if i want to have 3 input boxes instead of 4 and two output listboxes for comparison] i read in a CSV style file initially into the program giving the placement and type of edit boxes /list boxes/combo boxes/buttons etc that i want on each window .. because these are held in separate heaps it means that if i want to destroy and recreate the window in a different form then i can .. i think dialog boxes and mdi windows might be a bit restrictive anyway this is all programed and was surprisingly easy to do [compared to the stupid MS window stuff] ..
There shouldn't be any problem with doing this for MDI windows or dialog windows, in the end they're all still just windows and can be modified as necessary; but do what works for you.
Quote
the heaps for each window contain some information about theselves eg window handles id and placement but i now have the much more tricky problem of associating them with a process so for example if i want to add two number together i have to link the button/menu/mouse option in XXXproc that processes the window with say an add DLL .. unfortunately i decided the CSV file could come in in a fairly random order so i prob now have to have a window with [a many to many link] to a process table ??? .
Each module is just another function, so you can save the address of the associated function with each module and then call it when needed (standardising the module's execute function's parameters would simplify this.)
Quote
The idea is eventually to end up with something that looks a bit like a flowchart with boxes containing processes and links
If your aim is to have a single flow-chart in your main window then forget all the multi-window stuff - it will be simpler and more flexible to handle them as dragable 'objects' which you draw yourself (with lines connecting them up and directing inputs/outputs.)
If you want a flow-chart per child window, then okay.
Tedd .... thanks for your extensive and informative reply .. by the time id finished doing the other windows id pretty much understood the process of registration and ownership of the windows .. it turns out that now that ive got the hang of it i wouldnt say it would be harder than using MDI windows plus ive already written it and have prob more understanding of whats going on and ive made it do exactly what i wanted ...
as for the "flowchart" im putting them on the windows that drive/front each process and the main window is almost a placeholder for the matched or consequential data from each process ..
disappointed to find that the dlls arent in a separate process [and therefore privy to their own 2 gig ]..
i already used mapped files but its bl.. awkward !!!
many thanks for all the help Ill post the program on here when ive done the next bit and perhaps youd all be so good as to tell me how i can improve it
... regards mike b .
Tedd et al .. heres the program called emtree .. it uses two classes signified hopefully by different system colours [see WNDCLASSEX in the registration of the windows ]
1) click on new to create a new window with the same class from the opening menu ...
this should bring up a new window same background colour with a nice yellow treeview at the top of this window is a menu "Into the Woods"
2) bring down the menu and click on the top entry "List of Current Windows " which is a new class of window and should come up a different system background colour
3) on my computer the screen is a lurid blue and should be displaying a list of windows within the system [ enum windows ] if you now go to the Refresh list menu
Transfer List to comparison 1 will put all the windows into the second list box as a sorted list by handle
bring up a GUI program outside of this one eg notepad ....then come back into emtree and refresh the list [ top of same menu] but instead of transfering to list 1 move it to list 2 ... perhaps i should have compared the lists and highlighted the differences or only put thos in the second list either way its irrelevant as its only a tester
also
i didnt bother much with the structure .. its cut and paste and very clunky for which i dont appologise ... also the screen coords are just hardn wired so it may cover things it shouldnt ... also i didnt pay any attention to the screen order in relation to other screens so they may always appear topmost .. change it if you dont like it its not important as far as im concerned .. this whole window saga has wasted enough of my time regards mike b
You'll be pleased to know that after selecting the 'New' menu I'm presented with a shiny:
Quoteregister window one error 00000000 00000000
That's just a message box, and the rest of the program appears to function (as much as is left.)
im not bothered Tedd .. it works fine on the two different machines here .. regards mike b
Tedd i shouldnt have answered hastily and without thingking BIG SORRY as youve been kind enough to try it out .. the error is from RegisterClassex [first lot of zeros] it doesnt get to createWindow[ second lot would be a window handle] ... it works fine on windows 7 here and XP ... tried it on Wine but that fails registration prob at the same point . regards mike b
Tedd .. its probably because i seem to be able to Overload the Class in Win 7 etc but [i dont have win 10 etc] in Wine it wouldnt run unless i put the window which failed in a unique class .. i have been experimenting a bit as suggested by Hutch with the definitions ... oddly it doesnt like my definition of a Treeview which also works perfectly well in Win7 etc and so this doesnt appear on the now grey screen :sad: [< only slightly sad icon] but in Wine it now works ... i hope you will try it out for me [ i got a bit grumpy the other day as all i wanted to do was get on and write the maths bit and not pfaff around with all the GUI stuff.. which is only really handy because its easy to see the outputs ... otherwise Ruby [bit like old fashioned Basic] is good enough .. as an aside the notion of Types in languages strikes me as a big drawback ..anyway the altered version missing its bright yellow treeview is attached regards mikeb
ok it turned out that i didnt have InitUnusualControls in the program .. [as this was cobbled together as a tester :undecided:] and so SYSTREEVIEW32 which is an Unusual control it would seem wasnt present [as presumably a class ] so didnt register with a concommitant window handle .. hence never appeared within that window ... its now there in all its lovely yellowness looking quite disgusting and displaying its handle regards mike b
Well, it appears to work now - congratulations!
A few minor points:
- the yellow-treeview-window has on-top style for some reason (the others don't);
- the Exit menu and window X on the 'child' windows don't close the windows as expected, just minimises them.
Tedd many thanks .. yes i did fix those although i ought to park the main screen each time and allow clicking by say a double right click to reinstate it as in that test program i ended up using its listbox as a transaction log .. i realise now that testing on Wine is excellent as it reveals stuff that wont happen on MS specific op sys ... this program was just a tester . i started playing around with a mixture of menus and controls etc and have added a few bits would you mind if i mailed it to you ..not that i know how to do that on here !!!
regards mike b