How to add a Windowicon + Center Window? (again)
BlitzMax Forums/BlitzMax Programming/How to add a Windowicon + Center Window? (again)
| ||
| Hello! With the recent changes of bmx 1.24 and dxgraphics.bmx my former methods of adding an icon and centering a window doesn't seem to work anymore. Does someone know: 1. How to add a Windowicon? 2. How to make the gfx window center by default! without using maxgui? "Graphics 800,600,0" Thanks, Grisu P.S.: It would be REALLY nice if bmx could offer these things "out of the box". |
| ||
| Agreed (well, number 2 at least). |
| ||
| dxgraphics.mod/d3d7graphics.bmx - 'TD3D7Graphics.Create()' (249)... GLGraphics shouldn't have changed. |
| ||
| Thanks a lot Yan! Working perfectly... :o) |
| ||
| I haven't tried 1.24 yet so didn't know the (non module tweak) centering code no longer works. I'll have to check that out. I have a non-module tweak way of adding the icon btw. |
| ||
the non-module tweak centring code does still work:
Function ccCentreWindowHandle(hWnd%)
'Centres the current graphics window on the desktop
'Pass a handle in
?Win32
Local desk_hWnd% = GetDesktopWindow()
Local desk:TRect = New TRect
Local window:TRect= New TRect
GetWindowRect(desk_hWnd,desk) ' Get Desktop Dimensions
'Get Window Dimensions because final window may have been resized (by BlitzMax) to fit the desktop resultion! (Grey Alien)
GetWindowRect(hWnd,window)
'Centre Window
SetWindowPos(hWnd, -2, (desk.r / 2) - ((window.r-window.l) / 2), (desk.b / 2) - ((window.b-window.t) / 2), 0, 0, 1)
?
End Function
|
| ||
| Yes, but the problem is: It looks ugly when the window opens somewhere on the desktop and a second later it is moved to the center of the screen. Also, I don't want an extra function call for this. As said before centering a window on the desktop should be "default". |
| ||
| It looks ugly Yes I agree, I just don't want to make module alterations as that means anyone who gets my framework has to make them too, plus I have to "re-alter" them every time I syncmods. Totally agree it should be default or at least an option. |
| ||
| I agree too. BRL should make windows open in the centre of the display by default. I don't like messing with BRL's mods myself. |
| ||
| I would like centred default too, but there is a chance that it will break other people's existing code who want to open up several versions of the app cascading. However, most likely app writers are using MaxGUI and not Graphics w,h,0 which frankly is just for windowed mode games, and thus should be centred. |
| ||
Graphics 800,600,0,60,GRAPHICS_CASCADING or Graphics 800,600,0,60,GRAPHICS_CENTERED We've already got a flags param, should be easy to make this optional? |
| ||
| It's only a matter of time ... fingers crossed ;-) |
| ||
| As said before centering a window on the desktop should be "default". I just checked and it looks like the window created by Graphics automatically is created at the default position (in V1.24), so there's no need to change this. |
| ||
| Fabian: The default position according to Windows is to place in the top left in a cascading way. (i.e. each new window is a bit further right and down) GfK is saying that centering ought to be the default/standard BlitzMax behaviour. OR are you saying there is a Windows call that can be made to *change* the default position? |
| ||
| I would like centred default too, but there is a chance that it will break other people's existing code who want to open up several versions of the app cascading. They don't cascade anyway, the windows are created at '32, 32' (...?). This is the case for me, at least. Try it for yourself... |
| ||
| Oh OK, my mistake. Maybe it was blitz plus that cascaded. Doesn't seem to be 32,32 either, but close...maybe it's based on the client top left, ah yes that's it. Well in that case centring as default would be best. |
| ||
Sorry, I was wrong with what I said above, I just looked into the code, and yes it is 32, 32 based on the client's top-left:Local style=WS_VISIBLE|WS_CAPTION|WS_SYSMENU Local rect[]=[32,32,width+32,height+32] AdjustWindowRect rect,style,0 hwnd=CreateWindowExA( 0,_wndClass,title,style,rect[0],rect[1],rect[2]-rect[0],rect[3]-rect[1],0,0,hinst,Null )However I think the best alternative would be as Gfk said to decide whether windows default or centered using the flag parameter. |
| ||
| And one wish more for the new year, an easy way to provide your application with its own icon should be implemented too. The Gamemaker from Professor Mark Overmars can do that easily offering an option in the menue of the IDE, and BRL claims for itself: "dedicated to bringing you the ultimate in game creation tools and utilities". |
| ||
| Yes it would be nice as part of the IDE. I think that Protean used to do this but not for BlitzPlus only Blitz3D. |
| ||
| Bumped from the grave... I also want to request a flag to force graphic windows to open centered on the desktop. Sure, we can do it on Win32 with a few system-specific functions, but there doesn't seem to be any code floating around to do it on MacOS or Linux. Certainly BRL could implement this from the "inside" rather easily, right? |
| ||
| I'm surprised nobody at BRL has picked this up and fixed it by now. I could really use a solution for this. Grey Alien's code above complains that it doesn't know what a TRect is under 1.24. As I said above - I don't like making my own changes to BRL's mods, because the changes can be so easily lost. Tried Yan's code, though, and while it does work, windows still open in the top left corner under GL. |
| ||
That's my fault:Type TRect Field L%, T%, R%, B% End Type I don't like making my own changes to BRL's mods, because the changes can be so easily lost |
| ||
| GFK, just use an array instead. See the code I posted above. From reading the source (not that I've ever used objective C/cocoa), it appears that an OSX Max2D window already opens centered? I've got tweaked versions of glgraphics.win32.c and glgraphics.linux.c too (no icon for Linux version), but I don't see much point in posting them. |
| ||
| Yan - I don't understand where I'm supposed to make this change to get it to work under GL. I don't like even changing BRL's mods, let alone trying to comprehend how they work. |
| ||
| This is sort of a duplicate post because I just mentioned this in another thread, but centering a window on creation is really a matter of professionalism. It looks very unpolished for a window to pop-up in the corner of the desktop, and it looks just a bad to see it snap to the center. But more importantly, we need a cross-platform internal solution. Hacks for specific platforms just make for messy code and more problems. |
| ||
| Grey - your code still causes errors "can't convert Int Ptr to TRect" or something? |
| ||
| I meant for you to use the above code as an example of using GetWindowRect() with an array. Anyway, I've tweaked GA's code to use arrays... Function ccCentreWindowHandle(hWnd%) 'Centres the current graphics window on the desktop 'Pass a handle in ?Win32 Local desk[4]'[left, top, right, bottom] Local window[4]'ditto GetWindowRect(GetDesktopWindow(), desk) ' Get Desktop Dimensions 'Get Window Dimensions because final window may have been resized (by BlitzMax) to fit the desktop resultion! (Grey Alien) GetWindowRect(hWnd, window) 'Centre Window SetWindowPos(hWnd, HWND_NOTOPMOST, (desk[2] - (window[2] - window[1])) / 2, (desk[3] - (window[3] - window[0])) / 2, 0, 0, SWP_NOSIZE) ? End Function This'll work with GetWindowRect() as declared in PUB.Win32, which expects an Int Ptr. |
| ||
Try changing these lines :
GetWindowRect(desk_hWnd,desk) ' Get Desktop Dimensions
'Get Window Dimensions because final window may have been resized (by BlitzMax) to fit the desktop resultion! (Grey Alien)
GetWindowRect(hWnd,window)
to these :
GetWindowRect(desk_hWnd,Byte Ptr(desk)) ' Get Desktop Dimensions
'Get Window Dimensions because final window may have been resized (by BlitzMax) to fit the desktop resultion! (Grey Alien)
GetWindowRect(hWnd,Byte Ptr(window))
I've never quite understood why, but BMax sometimes implicitly casts between Byte Ptr's and Objects, and sometimes does not. Personally I'd rather it didn't do it at all, but since it does, it should really be consistent. ( I haven't run this, but I think that's probably what it wants. ) |
| ||
| GfK: It compiles on mine with Strict. You use superstrict or something? |
| ||
| It's because you've re-extern'd GetWindowRect() to use a Byte Ptr and GFK hasn't. I find it easier to just use arrays. |
| ||
very good Poirot.?win32 Extern "win32" Function GetWindowRect%(hWnd%, lpRect: Byte Ptr) ? |
| ||
| Elementary, my dear GA...Oh wait... |
| ||
| still not centered by default |
| ||
| If there was one dream-come-true scenario I'd like to imagine, then it was that beginners could find wonderful infos like yours without having to go through the entire forum to find important components...even if it's just one. LOL SO HERE'S ONE FOR THE ABSOLUTE BEGINNERS, WHO MIGHT STUMBLE INTO THIS THREAD: Global window =GetActiveWindow () 'to get the window handle! ccCentreWindowHandle(window ) '...well, calling the function, of course... I've really just started with BlitzMax about 5 days ago and am very happy in general until I get to OS related issues, silly as placing a window. That's when it shows that I don't know the first thing about Blitz, like how to get the window handle, hahaha... now i do. BUT, the above works, even with a little kink of not defaulting. I love the flag idea, too! That would be a beauty! Sorry, if I bounce in here like that, but I'm sure the next noob that stumbles into here will be happy! :) |
| ||
| You can't guarantee the window you create will be the active one (nor the one on top - yeah, I seen it!). Sometimes there is lag in the OS due to a slow computer or just one that is very busy. |
| ||
| Is there a way to get a Window Handle for the window created with Graphics()? Does the application know the handle of it's own window? It must do somehow. If we could get that, we wouldn't need GetActiveWindow() or the Mac equivalent. I'm gonna post this as a new topic... |
| ||
| Found this thread and tried the WINGW method of replacing the standart ICON for my app, but it somehow overwrites certain settings I've made for my own windowgadget. SetPanelcolor gets overwritten, offsets and the likes get screwed up, when I do the import... ?win32 import "icon.o" ? Is there something I'm missing or doing wrong? And how's that happening in the first place? Without the import everything's fine. (I'm not jumping the gun on this one!) |
| ||
| How exactly are you compiling the .o file? Here is how I would do it.. 'res.rc' (Fairly certain the newline at the end is necessary in someway or another) 101 ICON icon.ico 'buildres.bat' C:/MinGW/bin/windres -i res.rc -o res.o pause Open the batch file with command prompt (or enter the commands directly - make sure your in your program/import folder!) and it will generate the .o file. |
| ||
| yup, that's exactly what I did!? And again, it actually replaces the icons properly everywhere, window, file, etc... , BUT it somehow overrides those gadget settings of the actual code!? Totally bizarre, hm? I've done the other alternative, which works fine with the window and task list, but doesn't set the icon for the application. What a dumb hassle, haha... yikes. I'm certain there must be nicer ways of letting users set those icons properly. BlitzMAX team? That would be a real courtesy! Everything's so beautiful already... just consider it, please. |
| ||
| I think you need to put the icon in the same directory as the compiled .exe and give it the same name. For example, test.exe and test.ico. |
| ||
| The icon gets compiled into the .o file, so you don't need the icon present. |
| ||
| For use with MaxGUIEx... 1) Your object file *must* include a manifest. 2) It must be imported *before* MaxGUIEx (MaxGUI.Drivers). Here's a simple windres front end - MakeObject.zip ~100KB |
| ||
| OMG FINALLY...that's beautiful! Thanks, Ian! |
   |