Overriding Window.ClientHeight() ... Windows
BlitzMax Forums/MaxGUI Module/Overriding Window.ClientHeight() ... Windows
| ||
| Hiya, What would be the best way to override the Gadget.ClientHeight() command at the gadget level? Specifically a window. I need to add a small adjustment to the result but only for a main window. I only want to alter the result returned by a TWindowsWindow.ClientHeight() but without altering any of MaxGUI. Simply using the function ClientHeight(Gadget) won't work as the Gadget.ClientHeight() is used internally for calculations. So I'm thinking maybe some simple way of creating my own window type that derives from TWindowsGadget and I create my own ClientHeight() method, but it's not as easy as just doing that as it involves calling a whole setup process within MaxGUI which doesn't support my Type. I'm sure there must a better and easier way as I want to override that one method? Proxy gadget? Is that what I need? If so what's involved with getting a proxy gadget to work properly? All help and ideas are appreciated. Thanks. |
| ||
| I don't understand what you are trying to do. If you need to calculate a new window size and you don't know the value of the window frame (if that is the problem) you can use GadgetHeight(window) - ClientHeight(window) to find out. If you want to resize the window but you don't want to resize the gadgets on top, put them on an extra panel and set the GadgetLayout(Panel) to what you need, either to resize with the window or not. Or could you more explain what you want to achieve at the end. |
| ||
| Hi jsp, This is the problem... The UIRibbon interface HAS to be attached to the main window. When it gets attached Win7 actually moves the top of the window client area 30 pixels up into the titlebar and adjusts the client height to be 30 pixels higher in size. Somehow the algo used in TWindowsWindow.ClientHeight() manages to return the original value without the 30 pixel addition which causes all child gadgets to be 30 pixels higher up the window, leaving a 30 pixel gap along the bottom. It's taken me ALL day to find this one bug. Its sooo simple to fix, but as it is it means I have to modify the MaxGUI TWindowsWindow.ClientHeight() method to add the 30 pixels on. I didn't want to do that as MaxGUI isn't always going to be used with UIRibbon. So, I could write a whole load of Types and Methods that will derive from ( or Extend from ) the original MaxGUI Types, but it such a huge amount of code all because I want to just overload one simple Method. |
| ||
| This reminds me of MaxGUI Version 1.34 Before the toolbar was not taken into account into the client area, but versions above did. Does your ribbon interface change during runtime? If not, the programmer could take care as he knows when using the UIRibbon, although not the smartest solution. Maybe better: I could imagine a normal window gadget extended and overwriting your ClientHeight() and putting this into a proxy gadget to make it again a "standard" gadget. That should be MaxGUI conform. |
| ||
| The ribbon doesnt change in this respect during runtime. I know what you mean about the programmer but he/she doesn't have low enough control to overcome this bug though, the problem is the returned height of the internal ClientWindow which is just one step out of ( normal programmer ) reach at the MaxGUI level. I'm just looking for the simplest method possible. I was thinking of somehow using a proxy gadget but I've never experimented with them before today. I ( admittedly very quickly ) got something compiling but it would crash at the TWindowsGadget.QueueResize complaining of accessing a Null Object and I carried on with other areas while thinking before posting for ideas. I'll have to look deeper into the proxy gadget method as it seems the most sensible 'cleaner' way to go for me and definitely for the programmer. Ultimately I want the programmer experience as least confusing as possible even at the expense of a little more code in the interface. Do you have any heads up tips or gotchas with using the proxy gadget method? Is there a flag I need to set to prevent my previous error? I've since noticed the SetProxy method which I didn't set earlier and I imagine I do need to call it. I'll have a go with this tomorrow. Thanks. EDIT:-You can see the bug in the example pics I posted a while ago - the grey area at the very bottom of the window. For eg, in those pics the TextArea is set to the ClientHeight() already and MaxGUI doesn't know how take the adjusted height into account. Last edited 2012 |
| ||
| Don't know about this specific error condition - doesn't ring a bell, but yes the proxy method needs to be called. You would set the extended window as the proxy gadget. |
   |