app in release mode is behaving weirdly?
BlitzMax Forums/MaxGUI Module/app in release mode is behaving weirdly?
| ||
| Hey, I have not been building my app in release mode up until now but have today attempted to. Everything compiles fine but it seems that maxgui behaves very strangely in RELEASE compared to DEBUG mode. In debug mode everything works fine, no issues! In release mode some proxygadgets start to not draw and they behave differently. I have a locking mechanism on most of my custom gadgets that let me lock the gadget, make changes, then unlock. When the gadget unlocks it will do all the updates and reapint (redrawgadget) if needed. So there is potential that my code is not unlocking somewhere, but why would it work fine in DEBUG mode? Has anyone experienced weird issues like this when in RELEASE mode? Last edited 2012 |
| ||
| I have a lot of modules that depend on other modules and do a lot of tweaking of these modules. I am using BLIDE module builder to build modules. Do I need to build blitzmax modules in the order of dependency? Last edited 2012 |
| ||
| Just made all events output and it seems after a while EVENT_MOUSEDOWN stops firing.. wtf! |
| ||
| Did you updated your MaxGUI? What about debug and releasebuilds of the modules? Did zu try to just recompile all modules in threaded and not threaded mode? I had similar problems while using maxgui 1.41 with some gadget functions. A downgrade to 1.40 or 1.42 beta from repository fixed the problems for me |
| ||
| I've had those exact problems when using the os api ( and also with c/c++ ) specifically with callbacks, which is caused by using the wrong calling convention across languages. BMax adds extra code with debug mode that somehow lets you get away with using the wrong convention, but when in release mode it behaves incorrectly ( or correctly depending on how you look at it! ). Last edited 2012 |
| ||
| Ooo interesting thanks, I will look into both methods :D Any pointers on what you changed and examples would be very helpful? Thanks again :) Last edited 2012 |
| ||
| In debug mode variables are not freed as in release mode to be able to show the content in the debugger. I remember some problems related to that, when the GC frees variables at a time you didn't expect. Compared to Windows some events are fired differently on the Mac, which sometimes makes me crazy, but as your app works fine in debug mode that should not be your problem. |
| ||
| Any pointers on what you changed and examples would be very helpful? For the calling convention, specifically for Windows, the callbacks needs to conform to the windows convention ( all to do with the how variables are released from the stack ). Also, in BMax, the callback must be a Function as opposed to a Method. A method may work under certain circumstances, but it will certainly barf as the program size grows. Functions within Types are still ok. The calling convention you'll need for callbacks from windows will need "Win32" appended to the end of the function definition. Function WindowsWillCallMe(With,Various,Parameters)"Win32" 'Do something EndFunction I honestly don't know if the same applies to Mac ( it has calling conventions, all OSs do, but I don't know it's specifics or how would it relate to BMax ) so hopefully someone else could help out :P Of course it might not even be the problem, but it's a shot. |
| ||
| In debug mode variables are not freed as in release mode to be able to show the content in the debugger. I remember some problems related to that, when the GC frees variables at a time you didn't expect. Compared to Windows some events are fired differently on the Mac, which sometimes makes me crazy, but as your app works fine in debug mode that should not be your problem. I am able to avoid the problem if I turn off the garbage collector, but the moment I start to collect it throws a fit. So it seems something definitely happening with an unexpected release. I spent a day going over with a fine tooth comb, making sure all windows, gadgets, dialogues, resources, etc get freed. Seems like I will do some more investigation here too then. For the calling convention, specifically for Windows, the callbacks needs to conform to the windows convention ( all to do with the how variables are released from the stack ). Also, in BMax, the callback must be a Function as opposed to a Method. A method may work under certain circumstances, but it will certainly barf as the program size grows. Functions within Types are still ok. The calling convention you'll need for callbacks from windows will need "Win32" appended to the end of the function definition. Function WindowsWillCallMe(With,Various,Parameters)"Win32" 'Do something EndFunction I honestly don't know if the same applies to Mac ( it has calling conventions, all OSs do, but I don't know it's specifics or how would it relate to BMax ) so hopefully someone else could help out :P Of course it might not even be the problem, but it's a shot. Dave. Well I am not using any additional windows hooks as far as I remember and just tapping into the existing ones that maxgui uses. I have potentially not defined my header files for blitzmax properly with the extern c { thang so that could be bothering it? I'll need to investigate that one as well. Thanks all for the help so far. I will be sure to post my findings once I am able to resolve it. Hopefully it will help someone looking for the issue in the future. Last edited 2012 Last edited 2012 |
| ||
| Regarding Hummelpups post, what version of MaxGUI are you using? |
| ||
| I have potentially not defined my header files for blitzmax properly with the extern c { thang so that could be bothering it? Hmm, anything is possible, but if the source is c++ you wouldn't even get it compiled and have linking errors everywhere. Regular C externs doesn't normally require a calling convention as BMax defaults to using the "C" convention as opposed to "Win32". I don't think the problem now though. You mention using C, are you creating and passing BMax and C objects across the language boundary? Possible problems with scope can occur if thats the case. |
| ||
| Skid, I am using the version from the repo (hard to tell as the version number is stuck at ModuleInfo "History: 1.33 Release") I have made a few slightly modifications to add some functionality for some more events. One being a GADGETRESIZE event. Nothing major though. Anything that was modified has not really been anything that could break things apart from simply not compiling in the first place. Iam potentially creating some BBSTRING and BBARRAY for return values but have followed the same process as used by other blitz modules. There is never a point where I am creating a non-temp object outside of blitzmax scope. Could that still be an issue? Most of my wrapped stuff will be like: Last edited 2012 |
| ||
| Hi Jonathan, if you are stuck and want me to have a look please feel free to send me the project source. I would like to bump MaxGUI version for next release of BlitzMax so would be more than happy to make sure it is not something wrong in the module that is causing your problems. Last edited 2012 |
| ||
| There is never a point where I am creating a non-temp object outside of blitzmax scope. Could that still be an issue? As a say, anything is possible using BMax Objects outside of BMax, it is ok if you handle them correctly. Skid beat me to the offer of taking a look at the source. I don't mind looking too. The more the merrier to help get the issue resolved :P |
| ||
| Thanks for the offer. When I get a chance I will look into it more and then probably will fail that and send it over to one of you :) It is quite large a project though haha. It wont be soon, quite busy trying to get kickstarter project off ground but will post an update here when I had a chance. Thanks. |
   |