ClientWidth help from other OS's
BlitzMax Forums/MaxGUI Module/ClientWidth help from other OS's
| ||
I am working on a ProxyGadget and I need something from each platform. Could you post what this code returns for me?Strict Import MaxGUI.Drivers Global window:TGadget=CreateWindow(AppTitle,0,0,640,480,Desktop(),1+2+WINDOW_CLIENTCOORDS+WINDOW_CENTER) Global panel:TGadget=CreatePanel(5,5,150,ClientHeight(window)-10,window,PANEL_BORDER) SetGadgetColor panel,128,128,128 Notify ClientWidth(panel) Repeat WaitEvent() Select EventID() Case event_windowclose Select EventSource() Case window End EndSelect EndSelect Delay 5 Forever I get 146 and I'm on a Win32 system. |
| ||
| 150 on Mac OS X Leopard. |
| ||
| I get 146 too on Windows Vista with Aero enabled. Just looking at your code, I thought that I best mention that you should use the bitwise OR '|' operator instead of '+' to combine flags. Using '+' can sometimes give undesirable results. Strict Import MaxGUI.Drivers Global window:TGadget=CreateWindow(AppTitle,0,0,640,480,Desktop(),WINDOW_TITLEBAR|WINDOW_RESIZABLE|WINDOW_CLIENTCOORDS|WINDOW_CENTER) Global panel:TGadget=CreatePanel(5,5,150,ClientHeight(window)-10,window,PANEL_BORDER) SetGadgetColor panel,128,128,128 Notify ClientWidth(panel) Repeat WaitEvent() Select EventID() Case event_windowclose Select EventSource() Case window End EndSelect EndSelect Delay 5 Forever |
| ||
| On Ubuntu 7.04 (running on VMPlayer) I've got 150. On MacOS X 10.3.p (PPC) 150 |
| ||
| Topic moved to here. Man, I've been getting really bad about that. :P Just looking at your code, I thought that I best mention that you should use the bitwise OR '|' operator instead of '+' to combine flags. Using '+' can sometimes give undesirable results. Oh, OK. Thanks. 150 on Mac OS X Leopard. I get 146 too on Windows Vista with Aero enabled. On Ubuntu 7.04 (running on VMPlayer) I've got 150. On MacOS X 10.3.p (PPC) 150. Thanks, everyone! |
| ||
| Can I just ask why you are needing to hard-code the values into your proxy gadget? Is there a reason why you aren't simply calling ClientWidth() within your TProxyGadget? It's always best to steer clear of hard-coded values if you can help it, as even within one platform, the values can be different depending upon the theme uses etc. |
| ||
| Can I just ask why you are needing to hard-code the values into your proxy gadget? Is there a reason why you aren't simply calling ClientWidth() within your TProxyGadget? It's always best to steer clear of hard-coded values if you can help it, as even within one platform, the values can be different depending upon the theme uses etc. I was wanting to know the above information because I wanted the pixmaps to fit perfectly inside the panel. :) To make everything more clear, I just e-mailed you the completed proxy gadget. I would've posted it here, but it's kinda big. Let me know what you think and if I should add/remove anything. |
| ||
| Seb, I just realized that I slacked off on a bunch of crap in the proxy gadget I sent you. I forgot to add a vertical scrollbar, tooltips, and an option so that you don't have to use pixmaps for the pane headers (I'm thinking like a default color depending on each platform). Let me know if you want this new one when I finish it. |
| ||
| Hi Ked, Sorry, just got your e-mail now - I don't check that account too often... Had a look at the proxy gadget, and was intrigued looking at the name about what a collapse pane might be, but as soon as I ran the example, I saw and instantly realised it's potential usefulness. :-P Although it behaves well "as is", if you are serious about wanting to add it to the official MaxGUI.ProxyGadget it perhaps needs those few tweaks first. Firstly, if you could find a way to perhaps have collapsible panes that don't require a pixmap to be made for each state, and that allow horizontal resizes. I think people would use this a lot more if all they had to do was set the text. Perhaps this can be done by generating a tile pixmap automatically using a function similar to that in my TSplitter.MakeColourHandlePixmap() (see splitter.bmx). Secondly, vertical scrollbar would definitely improve the functionality and make it much more versatile when panes go off the screen. Thirdly, it occured to me that a few of the functions (e.g. SetCollapsePaneState() and RemoveCollapsePane()) closely follow the gadget item functions, so perhaps there is a way that it could be tweaked to make use of the functions already there such as AddGadgetItem(), SetGadgetItem(), SelectedGadgetItems() etc. This would make it feel a lot more like a standard MaxGUI control, but I've never attempted making a proxy gadget that behaves like list based gadgets so this might not be feasible. Still, very nice work - keep me posted here with any updates. |
| ||
| Seb, Hey, I have a slight problem when creating the text for the pane. I'm thinking that I'm going to have to switch to canvases to make everything look and work nice. Or, maybe there's a multiplatform GDI module laying around? I could probably use that. Let me know of your thoughts. :) |
| ||
| Hi, I'm thinking that I'm going to have to switch to canvases to make everything look and work nice It may just be a personal thing, but I really don't like using canvases for platform controls because of their dependence on hardware accelerated graphics drivers (such as OpenGL or DirectX). To my knowledge, there isn't a *cross-platform* GDI module (that can be easily used with MaxGUI), so I really don't recommend it. Try to work around canvases at all costs. I have a slight problem when creating the text for the pane. What exactly is the problem? Maybe I could suggest a solution? Cheers |
| ||
| What exactly is the problem? Maybe I could suggest a solution? I'm having trouble putting text and a pixmap into the same panel. If I use a label, the background is the same as the window/panel color. |
| ||
| I really don't like using canvases for platform controls It's not a very good idea at all. To my knowledge, there isn't a *cross-platform* GDI module It's called wxMax :-p that can be easily used with MaxGUI Ah... well... no. But with wxMax you can create all kinds of interesting looking controls with the GDI, which work the same on all platforms. Maybe someone can write one for MaxGUI? |
| ||
| But with wxMax you can create all kinds of interesting looking controls with the GDI, which work the same on all platforms. I would use wxMax, but I find it a waste of time. Code is longer, too much to import, and OOP is mandatory. I prefer MaxGUI. Maybe someone can write one for MaxGUI? Something tells me it's not that easy, or BlitzMax would already have a module for it. |
| ||
| Code is longer, too much to import, and OOP is mandatory. You are right, those are very good reasons to keep using MaxGUI! |
| ||
| You are right, those are very good reasons to keep using MaxGUI! Good enough for me to dislike wxMax. |
| ||
| Ok, Ok. Break it up you two! :P @ Ked: Does this not work for you? I know it's not a pretty example, but the background is definitely visible through the label text:  |
| ||
| What about the people who can only use the Win32MaxGUI module? |
| ||
| What about the people who can only use the Win32MaxGUI module Ahhh, now that is a different issue. The short story is that it took absolutely ages to get MaxGUI.Win32MaxGUIEx to handle this kind of thing properly, as most Windows controls are not transparent as standard. The most stable way to achieve the effect is to use some of the new theme API functions that first shipped with Windows XP (such as DrawThemeParentBackground()), and as such I can't really add it to the old legacy driver designed for people who need it to run on Windows 9X. I consider this less of a problem more recently though, as it is now possible to run MaxGUI.Win32MaxGUIEx on Windows 9X/Me, so long as you add... Import "-lunicows"...before the MaxGUI.Drivers import. Ked, is there a specific reason why you are using the old driver as opposed to the brand new (and more stable) one? |
| ||
| Ked, is there a specific reason why you are using the old driver as opposed to the brand new (and more stable) one? I'm not. I just want this to work the same on all drivers. Which brings me to my next question: Does your example look the same on Mac and Linux? |
| ||
| Does your example look the same on Mac and Linux? Although I haven't tested it on Mac, I think labels are properly transparent with CocoaMaxGUI, so it should do. As for Linux, I've just fired up my Ubuntu PC for you now, and the background shines through with FLTKMaxGUI. As such, I think you are pretty safe with using it. |
| ||
| Alright. Let the updating begin. |
| ||
| Just checked on Mac OS X for you now and, as I expected, the panel pixmap is visible behind the label text. |
| ||
| I'm having a crap-load of trouble with the scrollbar. Do you have an example of setting the range of it? Everything I've tried is all messed up. :P |
| ||
| Any ideas from anyone? |
| ||
| Here is a short example of a scrollbar. Normally you want to have a hook function for the movement to have an immediate effect. |
| ||
| That's great, but when you use the arrows it only moves one pixel at a time. Is there a way to move it maybe 20 or 30 pixels at a time, or something? |
| ||
| Just set the number of pixels to move when the event occurs. Use up and down key or the mousewheel. Here is the idea: |
| ||
| No, I mean the arrows on the scrollbar. Your code also doesn't stop scrolling, so you can scroll as far as you want. |
| ||
| No, I mean the arrows on the scrollbar. Ah, ok. Those arrows don't produce an own event, so you can't act directly on it. But you can check the slider value and set it to whatever you like when you recognize a 1 pixel shift... Your code also doesn't stop scrolling, so you can scroll as far as you want. That's right. It just shows an idea how you could catch some events and move the panel as you had problems setting the range of the scrollbar. I leave it up to you to create a working type :) |
   |