Differences between "Build & Run" vs "Build"
BlitzMax Forums/BlitzMax Programming/Differences between "Build & Run" vs "Build"
| ||
| Quick question: • I have a level editor program that issues HTTP requests to download assets • It does this all on the main thread (temporarily hanging the app while it fetches them --- this is cool for the Editor) • HOWEVER: it only works if we are in the IDE and "Build and Run". If we just build the app, and then double-click it and execute it manually, it hangs indefinitely right when the HTTP requests start (note: it does not actually download any assets, or even write to the log file) • "Build and Run" however does everything perfectly and the app behaves and logs as expected. Are there any known differences between running an app via the IDE vs manual execution? Thanks, Jason |
| ||
| there shouldnt be, have you checked if your building in debug mode? |
| ||
| Your sure no print requests? Dont forget you have effectively a canvas for output in the ide Edit: Shouldnt your question be Differences between "Build & Run" vs "Run"? Last edited 2011 |
| ||
| H&K: Thanks --> what do you mean by "print" requests? Do you mean as in standard output printing? Because we do quite a bit of that. And yeah, that title I put is a little misleading :) |
| ||
| Yes, but to be honest I tested it and I could only get it to "hang" on input requests |
| ||
| The only things I can think of are path-related or if it's running in debug mode - and it stops for an exception or debugstop. Why not try kicking it off from gdb? At least then you can (sort of) find out what it's doing when it locks up - well, not so easily as on Mac/Linux, but it might help. Also, you don't need to do blocking http requests if you think it's an issue. Libs such as libcurl have that facility. |
| ||
| I have a new 64-bit Windows 7 PC. With the "Build GUI App" option enabled Print works as expected in the IDE but seems to do nothing when running the .exe directly. With "Build GUI App" disabled, i.e. a Console App, Print works as expected. If this is the problem then it's probably best to get rid of Print entirely and use DrawText. I remember a similar issue when BlitzPlus was released. As a quick and dirty way to test old code I wrote functions to emulate Print and Write using Text and couple of Global variables for the (x,y) location at which to display the text. |
| ||
| I seriously doubt "Print" has anything to do with this... A GUI app's stdout just floats off into the ether somewhere. |
| ||
| Aren't you using any input sentence, are you? Try to run a console build from the desktop and see if the console window does have an clue. If the debuger starts, it will be waiting for a response in the standard input pipe, and on a GUI appliaction, this could be seen as the application is hung. |
| ||
| We aren't using any input aside from MaxGUI control widgets (menu, buttons, etc). Do you know what commands in BlitzMax would cause this type of input hang you describe? Thanks, Jason |
| ||
| Are there any known differences between running an app via the IDE vs manual execution? Environment / paths. You are building it in release mode or debug mode? |
| ||
| • HOWEVER: it only works if we are in the IDE and "Build and Run". If we just build the app, and then double-click it and execute it manually, it hangs indefinitely right when the HTTP requests start (note: it does not actually download any assets, or even write to the log file) Check your software firewall settings? |
| ||
| as Brucey said, start checking your OS and network settings. Are you using XP or Win7? Perhaps your exe does not have enough permission (like the IDE DOES have??) on the OS, and you need to run your exe 'As administrator' ?? (just guessing) D. Last edited 2011 |
| ||
| Thanks guys for the clarifications. We're running it in debug mode for the most part. I hadn't even thought about administrator access stuff. How would debug vs. release affect this? I think we see the problem happen in both anyway. |
| ||
| But you realise that if you run a debug app outside of a "debug" environment, if it drops to the "debug interactive mode" without a program to control it, it will appear to hang - as it is waiting for commands from the debugger. |
| ||
| But that should only occur if you have DebugStops, no? I had assumed (perhaps incorrectly) that it would be safe to use a debug build in a non-IDE environment because in the event of it crashing, the crash report generated by the OS would include more symbols instead of just memory addresses. Perhaps this is just the case with compiling apps in C/C++. Not sure! |
| ||
| No. If the app throws an exception (for example), it drops out to the debugger, providing it a file/line number and stack information. If you aren't running the debugger, it will just sit there waiting for commands from the debugger - which will never come. You should only really run debug code from the IDE. I did make a "remote debugger" appstub module once, which allowed you to run an app in debug mode which would attach itself to an external debugger... but it was never released... As well as running on the same machine, it also allowed you to debug across different computers/platforms. Interesting little project... |
| ||
| Brucey I would be very intersted in that project! I have to test my game on other computers online using friends who don't know how to program. |
| ||
| So what would explain an app still not running correctly when double-clicked from the Windows desktop, even though its built in release mode? What environment variable / path related issues may be affecting this? I've been unable to successfully compile the app on Win 7, and then double click it and have it run normally. Do it all from MaxIDE though, and everything's fine. Any more concrete troubleshooting tips you would recommend? |
| ||
| Try toggling the "Build GUI app" option. Turn it off if it's on or turn it on if it's off. Recently tried compiling a program that worked in the IDE, but did absolutely nothing when ran outside the IDE. Turned off the Build GUI App, and it worked fine. I guess it has something to do with the way Win7 handles console i/o when there is no console. |
| ||
| Thanks TomToad, I'll give that a try and report back! |
| ||
| One thing I just realized that complicates that solution is that we experience the problem with our Level Editor as well ---which is a MaxGUI app, and we'd need to have MaxGUI enabled... |
| ||
| Believe it or not, you can still build MaxGUI programs even when the Build GUI app is disabled. You will just get a console window open up behind the MaxGUI window. I originally thought that turning on Build GUI app merely suppressed the console window, but as I found out on Win7, it isn't the only thing it does. Another advantage to turning off Build GUI app is that all your "Print" and "Debuglog" output will show up on that console window. |
| ||
| Build GUI app is misleadingly named. It has nothing to do with graphics or gui. It PURELY means whether you get a console window appearing or not. |
| ||
| Wow, totally didn't know that. I'm guessing that's probably old news for most. Thanks for the info :) |
   |