I do a lot of cd-roms using as2 but recently when I try to publish an exe file the full screen fs command just now freezes my exe file. I've seen the other post here about double quotes and changing case but is there any other new thing that makes it not work?
I don't think that projectors rely on the flash player's that your browser does, it's not updated as often as the browser, It's embedded into the exe. Thus, unless you've updated flash (the actual program), the version is the same as the one that published your previous projector. (Assuming you're talking about not previously having this problem)
However, you may have updated your video driver, or something with your operating system that would be causing the lock up.
What you can do, is try and see if there is an update to your suite. You also could try reverting to a non updated version if you did update.
Besides that, I suggest trying the projector on multiple computers to see if the problem is consistent.
Related
I am at my wits end. I've written a xul app and it runs fine if I open the .xul in firefox directly. But xulrunner doesn't cooperate at all. I can run my xul fine by using the -chrome flag for firefox and giving it an absolute path, but -app doesn't work on firefox either. I have all the files required (application.ini, chrome.manifest both in root and /chrome/ and tried with either missing as well) and their format has been checked and re-checked.
I was prepared to paste all my files here and link the code, but I've tried everything, including a boilerplate project from http://www.mozdev.org/projects/wizard/ (from the application wizard) which reacts the same way as my own project.
xulrunner returns no error message, nothing - it just stays there in the task manager, no cpu load, not loading anything to memory, inert.
I've tried other projects (https://github.com/matthewkastor/XULRunner-Examples - the periodic table works at least) but I can't get a single solid lead on why some projects run properly, while others just have xulrunner waiting and doing nothing. It also seems this is a rare problem because most people can at least run the boilerplate fine, even if their own projects don't initially run.
I don't think it's necessary to post my code at the moment since it behaves the same way as the boilerplate. Can anyone tell me possible reasons why xulrunner won't work with the boilerplate but will with the example project?
I'm running v25 on win xp sp2 and I have been searching and reading all day, so I'm pretty sure I've read everything related - thanks in advance; I hope 5 days of work won't be wasted :(
edit:
SOLUTION: I messed up and didn't notice that prefs.js was missing or empty. Even if you have no preferences in your app, prefs.js is needed to set up the environment and tell firefox or xulrunner where the xul file to start from is. Without this pointer it has no idea. Yes, the MDN article does state this and what it contains is accurate, this was a big mistake on my part, as it seems I subconsciously (or not?) ignored the prefs.js file because I had no need for preferences in my app.
tl;dr if your apps don't work but the example files do, check your prefs.js even if you don't use preferences.
Posting this to close this question, since it doesn't need further answering.
The fault was with me - the app required a valid prefs.js file which I hadn't created because I was under the impression it wasn't required unless you intended to have preferences in your app. The MDN (at least at the time) specified this.
I've built a pharo application that I want to give to my customers. The application is based on seaside and will run headless. For this I don't need the .source and .changes file. I would like to save some space in the distribution archive and therefor I'd like to skip those files.
At the moment it appears to me that pharo is complaining anyway if those files are missing. Is there a chance to start the image without .sources and .changes file?
From Sven Van Caekenberghe:
SmalltalkImage
checkSourcesFileAvailability: false;
checkChangesFileAvailability: false.
And then save the image.
Yes it should run just fine. It should only show an error-message in the GUI but the main thread should keep running, and since you are running headless (i have made better experience with -nodisplay btw) your clients will not be able to see the message.
A simple matter makes me suffering as I'm new to PyS60 development.
What is the IDE for
Executing program on-device with a single reasonable amount of clicks,
Typical step-into, step-over, run-to, watch (used from PC) for the on-device running program ?
Real on-device debugging is not (yet) possible, I'm afraid. You have to use popup notes, audio.say() or write to log files.
Personally I forward sys.stdout and sys.edterr into a log file and use sys.settrace() and
sys.setprofile(). Works reasonably well, no need to modify real app source code, just dump EVERYTHING into a log file and do search afterwards.
Sometimes, a customer (or tester) needs a patch on an installation of the product I work on. Sometimes, I brew him a dll containing the fix, so that he can test it. He overwrites the old dll with the new version and restarts the app.
Every now and then, it appears that the 'new' dll isn't actually used, although I'm absolutely positive that my brand new sparkling bytes were copied over the old dll.
To make things worse, after the first 'hotfixed' run, when restarting the application, the new functionality clearly is loaded..., and the old behaviour is never to be seen again.
Has anyone observed this behaviour? Would it be possible that the XP loader sort of 'caches' recently used dlls?
(Note: this happens on XP SP2)
Yes, this is possible. Windows does not let you delete files which are in use, but strangely enough (for Windows at least) you can rename a DLL while it is still in use. If your tester uses something along
rename dll to dll.orig
copy new dll
restart application
it can happen, that the dll.orig version is still used if it has not been completely unloaded (because some still started app still has a reference to it).
This has bitten me a few times, too. I therefore usually change some behavior (mostly something of the header of the log-file) so that I can be sure that something has not been happened.
To workaround is simply: close all programs that use this DLL. Sysinternals Process Explorer helps to find the applications that use it.
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?