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.
Related
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.
I'd like to create a Powershell script to press the next button in an installation wizard.
I'm troubleshooting a script that a client wrote to help them automate the process of installing software. This script can allegedly fully install any program (with some small amount of customization from program to program).
Now I've gotten it to work to a point where it launches the install wizard, but then nothing happens. Their problem only happens further down the install process, but I can't seem to figure out why the first part of it being able to press next doesn't work.
I can provide code if necessary.
What line of code I should look for in the script that could make the script push the "next" and/or "continue" buttons?
Can you? Probably.
Powershell has access to .Net API and even native Windows API, so you could go low-level enough to enumerate windows in the installer window, find the window labeled 'Next' and send a pair of mouseDown, mouseUp events to the button.
Should you? Probably not.
As mentioned in comments, any good installer system supports some method of installing silently. MSI, if I recall correctly, has a way of recording manual steps performed by a user and store them in a Response File. Then you may pass the .rsp file in later executions of the installer.
See other answers:
How to make better use of msi files
I wrote an extremely lengthy script that creates a form. The main purpose of it it to connect to vCenter servers, total up hosts/vms within different datacenters and also identify ESXi host versions. Running the script in ISE the form loads fine and when I click the Button to start the many various functions to update the fields, it runs. I have Foreach() fields throughout and added in a little StatusLabel to the bottom of the form to show me where in the script it is currently scanning.
Once all was done and working, I saved the PS1 file and moved it to a shared server to be run. When I run the Powershell console (as Admin) and point to the file, the Form loads ok. Once I click the button to begin generating the info, It just changes to (Not Responding) and grays out. I know it's working and if left there long enough it will return the info.
Why does the console window not function like the ISE? I want to be able to see the information and Status Label update/change as it goes through the script (just like I do in the ISE).
Appreciate the feedback. The script is several thousand lines long and would need to be scrubbed before I upload. Was hoping to just get some general info before doing that.
I updated to v4 and verified that my command window was running as STA using the command from Jan Chrbolka. Script runs properly now.
I was also facing the same issue.(Btw, I cannot upgrade Powershell to V4 right now since it is my company owned one.)
The Browse button that I incorporated in my form was not working when I am lauching it from Powershell command line. It went to Not Responding state when I click the browse button.
I took the advise from Jan ChrbolkaMay about the STA and MTA.
I checked for the threads related to that and changed the script execution format to the below one which fixed my issue.(adding the word -STA)
powershell -STA -File D:\PS\GUI.ps1
For checking the current state. Use the below query in Commandshell as well as ISE.
Before I ask anything, let me tell you I have no experience whatsoever on Progress Openedge, but my company runs an application made in it and now I have to make some SOAP calls through it. So I figured, why not call an external script made in whatever language I deem fit?
But I can't even find how to run an external script through OpenEdge when I google for it. There's no examples anywhere, the documentation is long and confusing (for me at least). That brings me to this simple question:
How can I call an external script in Progress OpenEdge?
Try OS-COMMAND.
See Progress Knowledge Base, too.
And a complete description on how to interact with your OS.
I had a similar problem and ended up using this in a Windows application:
OS-COMMAND NO-CONSOLE "program_executed_here".
The lack of a "NO-WAIT" means my progress code waited until the command was finished (which I needed). The NO-CONSOLE keeps Progress from popping up an annoying console window after the OS command finishes running.
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.