Syncmods Changed QueryGadget?
BlitzMax Forums/BlitzMax Programming/Syncmods Changed QueryGadget?
| ||
| Let me be clear that I'm *NOT* including dev.win32maxgui in my project. I removed it altogether to make sure. It's whatever came in syncmods which has changed this, nothing else. Just did a syncmods today because I wanted to help test the latest beta of Win32MaxGUI and now my main project ( which was working perfectly when I went to bed last night ) is crashing on startup. The line MaxIDE highlights is this line : QueryGadget(TVCanvas,QUERY_HWND) Well technically, there's more to that line, but it's where I pass that line to my game engine, which uses the HWND to open Graphics window. I get an unhandled memory exception error, so either QueryGadget is returning an invalid hWnd or MaxGUI has somehow been changed and is doing something to interfere with my graphics engine using the hWND of a canvas to open a D3D9 graphics context. This is kind of a problem because it completely breaks my project. I can't do a single thing until I can get this back working again because the game engine and the development environment are one and the same. |
| ||
| Not to appear sour or impatient, but this has now cost me two entire days of work. I just can't lift a finger without this being fixed. I don't know what it is. The debugger is pointing to that line, but clearly that's the trigger, not the actual point at which there's an error. I can't write a better debugger though. If it's not query gadget and if Canvases are returning valid hWND's then something has changed with canvases to stop me using them as D3D9 windows. Are you attaching Max2D contexts to them? Is that causing it? Have you changed event handling for them in the latest syncmods? Is that it? |
| ||
| This is offtopic but I'd like to see a concise history of all changes made to all modules, including dates. My own programs have been scuppered with a simple Syncmods, and a list of whats changed would make it easier to figure out what's gone wrong. |
| ||
| I completely agree, GFK, and I've requested such a list before. It's always painful when an update breaks your code completely, but it would be a little less painful if we knew where to begin looking. |
| ||
| Ahem. |
| ||
| First up, please turn quick build off, syncmods should probably completely clean .a files out or at least disable fast build, time and time again I have had to... Second, are you using any max graphics drivers on the canvas? Did you triple check you removed all references to dev.win32maxgui with quick build disabled. Perhaps delete the module to be sure. |
| ||
| Quick build was never on. I never have it on. For some reason it always messes things up. No, I'm not using any max graphics drivers on the canvas. I deleted the dev.win32maxgui module before posting the first time. I should have been clearer, but that's what I meant when I said I removed it altogether. |
| ||
| Sorry to not be much help, I would revert to a core122 installation next and confirm syncmods of brl/pub is 100% the problem. |
| ||
| Ok, done that, and I can confirm that whatever was sync'ed in brl/pub has broken it. |
| ||
my version diff program lists the following, unfortunately it could easily be missing some,+ (BRL.Blitz) String.Find now converts start index <0 to 0 + (BRL.FileSystem) Fixed RealPath breaking win32 //server paths + (axe.jasper) jasper_config.h fix for gcc4 compatability + (axe.lua) removed luac.c from build list + (BRL.Map) Restored KeyValue enumerator + (BRL.Map) Added Copy method + (BRL.Map) Fixed Clear memleak + (BRL.MaxGUI) Added RemoveHotKey Function + (BRL.MaxGUI) Bumped for popupmenu method change + (BRL.MaxGUI) Bumped for new TMap + (BRL.CocoaMaxGUI) Fixed gadget and extra data fields for EVENT_GADGETMENU node events + (BRL.CocoaMaxGUI) Added itemx extra object to relevant GADGETACTION events + (BRL.CocoaMaxGUI) Tweaked bounds checking on textarea CharAt and LineAt + (BRL.CocoaMaxGUI) Fixed keyboard filtering bug introduced in 1.23 + (BRL.CocoaMaxGUI) Bumped to keep in sync with new TMap + (BRL.Win32MaxGUI) Fixed SetGadgetHotKey not removing original accelerator + (BRL.Win32MaxGUI) Fixed GetDC(0) leaks + (BRL.Win32MaxGUI) Fixed tabbing problem with panel_group children + (BRL.GLGraphics) Implemented Brucey's linux window title fix + (BRL.Pixmap) Added new GL compatible pixel formats + (BRL.PNGLoader) libpng update to 1.2.12. + (BRL.PNGLoader) Extra load error handling. + (BRL.Stream) Fixed 'excpetion' typos + (BRL.System) Fixed unretained object issue with mouse tracking + (BRL.System) Fixed windowed mode HideMouse issue + (BRL.System) Fixed win32 requestfile default extension bug#2 + (BRL.System) Fixed win32 requestfile default extension bug + (BRL.Timer) 1.02 release + (Pub.ZLib) Updated zlib to 1.2.3 sry if you already know this - when the debugger stops and highlights a line, double click in the navpanel on the bottom most function to open the exact location of the crash, the only reason I can think is your TVCanvas is null. The debugger will be able to tell you that. If BlitzMax starts behaving too bizarre I always test with garbage collection disabled also. |
| ||
| EDIT: Old stuff removed, I have better information now. I tried replacing the modules one by one with their old versions pre-syncmods. Replacing the Map module with the pre-syncmods map module fixed it. So it's not the canvas. It's something which has changed in Map. For some reason, replacing the TMap module and then putting the new one back has caused the debugger to start working properly again. I can now consistently make it error on this line in TMap : Method ValueForKey:Object( key:Object ) Local node:TNode=_FindNode( key ) If node<>nil Return node._value <<< This line End Method Any ideas? I'm still fairly new to TMap's so it's possible that I've been misusing them and the old module let me get away with it, but I'll have to look in more detail. |
| ||
| The problem with map as I remember was a new method was inserted into the middle of its type which mangles all modules that invoke map methods. I think the problems is makemods is not spotting the change correctly so you need to rebuild all modules each time you modify map. This suggestion has a 85% likelihood of being entirely unfounded. |
| ||
| Phew! Thanks heaps, that was the problem exactly. I have a data structure called TreeMap which uses TMap and it must have been mangled as you suggest, because it's the only module I hadn't recompiled. Recompiling that has fixed everything. Thanks again. |
   |