I have an application whose installer is built with Install4J and when I run the Windows installer exe file the GUI doesn't appear until after about 15 seconds. During this time, there's an empty console visible to the user, and they may get the impression that nothing is happening.
What I'd like to do is simply print a message to the user, so they know the installer is running prior to the GUI appearing (or some other solution with a similar effect).
I added an action to the "Startup" section of the Install4j config that prints a message to the console. As far as I can tell, this is the earliest I can configure Install4J to do an action. It works great except that it doesn't print until after the GUI has already loaded, which defeats the purpose. It's currently the only action in the "Startup" section - moving our other startup actions to happen later didn't have any effect on how soon the message is displayed.
In the i4j_nlog_1 log file, it says what was happening during those 15 seconds before the GUI appears. ~5.5 seconds are verifying integrity, and ~7.2 seconds are extracting/creating. Ideally, I'd be able to print a hello message prior to any of that.
By default, installj4 immediately shows a native progress dialog when the installer is executed.
It is possible to deactivate that progress dialog by deselecting the "Suppress initial progress dialog" property on the "Installer" node in the "Installer->Screens & Actions" step.
Related
I'm using "AppMutex" in an Inno Setup script to make sure the product is not running anymore while installing an update. This basically worke fine.
But when running this setup with the "/verysilent" command parameter a dialog box is shown (although being very silent) that the program is still running and should be closed.
As the program itself is closed automatically and this may take only up to few seconds to be closed I just want Inno Setup to wait till the mutex was disposed and then start the installation, but not show any dialog box to the user in the meantime.
So is there a way to make Inno Setup just wait till the mutex was disposed when running with "/verysilent" and not show any dialog box about that to the user?
Thanks in advance for any suggestions on that!
There is no explicit way to suppress this message. However, you can suppress all the message boxes if you specify also the /SUPPRESSMSGBOXES parameter for the command line:
setup.exe /VERYSILENT /SUPPRESSMSGBOXES
If suppressing all the suppressible message boxes wouldn't fit to your requirements, you can wait for the mutex to be released (wait for your app. to terminate) by yourself in a loop with the CheckForMutexes function in an event fired before the setup performs this check.
We have a legacy server service running on a Windows 7 desktop that keeps crashing with a popup window reporting a memory error. The popup stops all processing on the machine. Once the "OK" button is clicked on the popup the system recovers and moves on. The root problem appears to be inside a compiled DLL that the application uses.
This popup usually happens between 9pm and 11pm every couple days.
It happens when no one is signed into the PC, so the popup displays in front of the CTRL+ALT+Delete message for signing in.
I can click OK and it continues processing, signing into the computer.
CHALLENGE:
This is a legacy application that will be replaced when budget allows (maybe next Summer) so there is no budget for upgrade or paying a consultant to fix the root problem.
All we need to do is click the OK button when the "Application Popup" event is thrown (logged in the Event Manager)
I know that it would be WRONG to write a script to satisfy the popup. Fixing the root cause is the CORRECT action.. but we have no support to spend money at this time. And since it's a compiled DLL, we can't fix the code.
Is there a PowerShell script that could:
Watch for a specific event "Application Popup" and if it occurs simulate pressing the ENTER key?
Run in the background, signed out of a user account.
If PowerShell isn't the answer, is there a better macro or script tool to get us by?
I know it's "bad practice" but we just need to get along until we get some budget dollars.
Powershell probably isn't the best answer in this case. I'd suggest using something like AutoIt (the WinWaitActive function would be useful in your case).
I have used AutoIt in the past and have found it very useful for Windows GUI automation.
Does eclipse remember when a program was executed last time? I know there is run configurations, but that doesn't keep track of past executions and their order of execution.
When a program is executed at the shell, then shell keeps tracks of the order of their executions? I want similar utility in eclipse along with the time of execution.
You can see in the debug view or in the console view (click the arrow near screen icon) the program that have run and the start time.
Edit : In Preferences/(Run/Debug)/Launching uncheck the "Remove termined launches when a new launch is created".
This list is reset if you clear hit or if you close Eclipse.
If you want a more permanent information, I think your programs should log that info in files.
you can execute your previous most recent program with ctrl+f11. For detail you can go to run->run history.
If you need the time when your program was executed, make your program output the time by itself. There is nothing in Eclipse that can do exactly what you need.
I have sort of an unorthodox question/idea. I have a hydrological modeling program that is a bit buggy. I do not have access to the source code. This modeling program runs 24/7 and periodically produces assertion errors (and sometimes runtime errors) and a resulting pop-up window. Often it produces a "Send Error Message/Don't Send" pop-up only. See attached .jpgs for examples.
These windows halt all further program execution until it is dismissed (by clicking "Ignore" "Don't Send" or "OK" respectively). The assertion errors do not appear to affect program function. From the investigating I've done on dbheap.c it is likely an issue with the modeling program deallocating memory improperly at the end of a run.
I would like the program to always continue running and producing its forecasting export products even in the event of one of these errors (which, again, appear to have no effect on program function). I would like to dismiss these pop-up windows from outside the application (via a script) so that they do not halt program execution. Does Windows have a means for monitoring and/or dismissing program generated pop-ups from outside the application?
You could write a simple application which forces the application to do things. With Winspector/Spy++ or Winsight you can see all the objects in a windows application. You could check periodically for a popup and then click a (maybe always the first) button. Windows has a API/syscall and with it, it is possible to send a message to a window (handle) of your choice (http://msdn.microsoft.com/en-us/library/windows/desktop/ms644944(v=vs.85).aspx).
Logged into my Windows XP SP2 computer using my normal user account (which has Local Admin privileges), when I start the BDE Administrator -- either from the Control Panel or from the BDEADMIN.EXE directly -- I never get the GUI. It shows up on my task bar, and shows up in the Task Manager, but the GUI never appears. I can close the program by right-clicking on the task bar and choosing close. (note that "never" means not within 5 minutes of launching the program)
If I log into the same exact computer using a different user account (which also has Local Admin privileges), when I start the BDE Administrator, it loads the GUI within a couple seconds.
I used to be able to use the BDE Administrator while logged in under my normal user account, so it's not like this has always been a problem.
While this issue may not be directly programming related, it does make developing and testing a pain when I have to log off and back on a couple of times just to make changes to my BDE configuration.
I am totally stumped. Any idea what might be causing this odd behavior?
One idea is that you may have had two screens running on this box and dragged the window off screen.
Just search for the registry keys that control where the window opens up and delete them. Alternatively, you should be able to right click on the program in the task bar and select Move. Then use your arrow keys to bring it back.
Regardless, I'm voting to close.