WINDOW_CHILD windows without blue title bar
BlitzMax Forums/MaxGUI Module/WINDOW_CHILD windows without blue title bar
| ||
Strict
Framework brl.blitz
Import maxgui.win32maxguiex
Local W = 400
Local H = 400
Local X = ( ClientWidth ( Desktop ( ) ) - W ) / 2
Local Y = ( ClientHeight ( Desktop ( ) ) - H ) / 2
Global Window:TGadget = CreateWindow ( "Window" , X , Y , W , H , Desktop ( ) , WINDOW_TITLEBAR | WINDOW_RESIZABLE )
W = 200
H = 200
X = ( ClientWidth ( Window ) - W ) / 2
Y = ( ClientHeight ( Window ) - H ) / 2
Global SubWin:TGadget = CreateWindow ( "SubWin" , X , Y , W , H , Window , WINDOW_TITLEBAR | WINDOW_RESIZABLE | WINDOW_CHILD )
Global Ending
AddHook EmitEventHook , Hook
While Not Ending
WaitSystem
Wend
Function Hook:Object ( id , data:Object , context:Object )
Local Event:TEvent = TEvent ( data )
Select Event.source
Case Null
Case Window
If Event.id = EVENT_WINDOWCLOSE
Ending = True
EndIf
EndSelect
Return data
EndFunctionproduces on my windows (XP): The title bar isn't colored blue, even if I click on it. However other applications using child windows like Microsoft Photo Editor do color their child windows' title bar blue |
| ||
| The effect you are looking for is called an MDI (Multiple Document Interface) layout, which isn't supported by MaxGUI. The child windows in MaxGUI are only supposed to be used for things like floating tool windows etc, and so the OS decided they shouldn't appear to have focus. |
| ||
| After a long time I just had a look at this old topic again, and noticed that WINDOW_CHILD isn't supported anymore. Do we have a chance that MDI will be added as feature in the future? I can't know, however, I assume that many MaxGUI users would be glad about being able to write MDI-based applications... wouldn't you? |
| ||
| I can't know, however, I assume that many MaxGUI users would be glad about being able to write MDI-based applications... wouldn't you? I did, but instead of MDI, I wanted tabbers and their a right arse on... Quickly found out MaxGUI doesnt have MDI... I moved the whole project to C#, with MDI, and its been a breathe of fresh air! :) For app development, I wont even touch MaxGUI again. Dabz |
| ||
| Do we have a chance that MDI will be added as feature in the future? Probably not as MDI is extremely old-school! Multiple windows, tabs and floating tool windows are the way forward. Even Microsoft Office (with Excel being the exception) stopped using MDI a long time ago. |
| ||
| For app development, I wont even touch MaxGUI again. There are of course, other, better, choices for app development in BlitzMax... which does include MDI, and is cross platform. I wouldn't recommend using MaxGUI for anything "complicated"... if you need a few buttons and a simple listbox, sure, but after that....... :o) |
| ||
| Someone once would've said that it would be complicated to travel to the moon and back.. :P Whether MDI is good or bad, I think a GUI should support it and hand over the possible compatibility risk to the creator, as well as the subjective opinion whether MDI is good or bad. One thing to learn from creative people (and creative tools) is that there are no rules. Ten academic people can advocate why MDI is bad, but if there is a single artist who really has a purpose for MDI, does that still make MDI bad? |
| ||
| Ten academic people can advocate why MDI is bad, but if there is a single artist who really has a purpose for MDI, does that still make MDI bad? Are you really suggesting I spend my free-time coding patches for that one in ten person who thinks that MDI is what they want? Surely MaxGUI needs attention in places where most people will find it useful. Whether MDI is good or bad, I think a GUI should support it and hand over the possible compatibility risk to the creator, Apple, the supposed forefront in GUI design, would strongly disagree with you there (have you read the Human Interface Guidelines). Even Microsoft have become a lot more strict recently with letting the programmer hack away of user interface standardization. But that's a completely different matter... |
| ||
| Surely MaxGUI needs attention in places where most people will find it useful. Well, it seems there are a least two users that would have found it useful... The Mac implementation of wxWidgets allows the use of MDI, except it works in a way where your Child windows are just child windows, not embedded ones... but it does as it would be expected, I suppose - same for Linux. On Windows, they are proper MDI parent/child frames. I'm all for choice. The more choice a developer has, the more stuff he can simply ignore. I'm sure most of the stuff I've implemented will never be used - except by Plash, probably. |
| ||
| I'm sure most of the stuff I've implemented will never be used - except by Plash, probably. :P I moved the whole project to C#, with MDI, and its been a breathe of fresh air! :) C# is reallly nice for apps, however, I usually find myself using BlitzMax when it comes to Linux simply because it *just works*. |
| ||
| Apple, the supposed forefront in GUI design, would strongly disagree with you there (have you read the Human Interface Guidelines). Once I've read 'some' guidelines, but I believe it was on some Linux website. In any case, there's only 1 person who decides what interface a private tool should have: me, myself, and I. Not Apple, not Microsoft, nobody except me. And if I want to use an MDI then what are they going to do about it? Here's perhaps something to think about: If the whole world agrees on the interface of a piano, does that make a violin builder stubborn then? And before you answer: "a violin has more playing functionality than a piano", I could answer: "dedicated/special controls could offer more functionality than the standard ones". With that in mind, what about my spinner (see some recent debate about it)? It does offer a lot more functionality than standard OS spinners (which btw are not natively present in BMaxGUI), yet it's a 'dreaded canvas object', probably not designed like Microsoft and Apple would design it. And yet it's so useful and feature-rich. |
| ||
| And if I want to use an MDI then what are they going to do about it? Quite simply, if you want to do something that the system doesn't support natively, you should be prepared to code it yourself. We could argue until we are blue in the face about violins, MDI windows and a coders right to design their own interface, but MaxGUI, unlike wxWidgets, isn't (and doesn't pretend to be) a complete GUI toolkit for advanced programs. If you want to do anything out of the ordinary, you should probably look elsewhere. The Mac implementation of wxWidgets allows the use of MDI, except it works in a way where your Child windows are just child windows, not embedded ones... I'm not sure how I've managed to annoy so many people, but this is effectively what I've been saying. MDI WINDOWS (IN THE SENSE OF A WINDOW *WITHIN* A WINDOW) AREN'T SUPPORTED NATIVELY ACROSS ALL PLATFORMS.. MaxGUI can have child windows, but we don't try to pretend we support MDI when it simply doesn't on other platforms. Native MDI isn't cross platform. |
| ||
| C# is reallly nice for apps, however, I usually find myself using BlitzMax when it comes to Linux simply because it *just works*. Yeah, its great... I'm an old Blitzer and do tend to expect more out of a BlitzBasic language than I should, or should know better too! ;) I quite like MDI, especially on a decent sized resolution, tabbers are an option, but are a pain in MaxGUI (Which I found). And like Brucey mentioned... Having a choice is better than having non at all. Still, I've had to slide from one language to another, which was pretty painless in the convert code department since they are very similar. Now I can go forward with my development instead of battling with mundane GUI tasks... And I'm happy about that now! :D Dabz |
   |