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).
Related
I'm using DrRacket to develop R6RS programs but I often see a bug where DrRacket hangs when either clicking on Check Syntax or Run. For example when checking syntax the message 'Check Syntax: expanding expression' is displayed at the bottom of the DrRacket window but no progress is made. Clicking on Stop shows the error message
C:\Program Files\Racket\collects\compiler\cm.rkt:213:2: user break
As far as I've been able to tell the problem always happens when running a program that imports a user library. I'm able to run the user library directly but for some reason there a problem when importing that same library into a program. I'm also able to use raco make on the same program without any issues, so I don't think there is any problem with the code.
A few more details. When I see this problem the Windows Task Manager shows that DrRacket is consuming no CPU (although a lot of memory). The memory use indication at the bottom right of the DrRacket window is ticking over, showing that DrRacket has not completely frozen. This feels like a thread deadlock situation to me. I have the latest version of DrRacket (8.7).
Any solution or workaround would be appreciated.
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'm testing a custom WPF application using pywinauto.
When connecting with win32, I don't get any dependents, so I'm connecting with uia.
After I launch the application, I can immediately connect with pywinauto, but it takes 30s+ before I'm able to access any elements. After the initial delay, interacting and searching for controls is quick.
I call windows() as a way to wait until the application lets me interact with it.
main_app = Application(backend="uia").connect(path=APP_PATH)
main_app.windows()
On investigation, the hanging seems to occur during: "application.py" > "windows" > "findwindows.find_elements(...)" > "element.children(...).
If I open the application, and wait for 1 minute, and then run the script, then it occurs almost immediately. And finding subsequent controls is quick.
I appear to see this same behaviour when using inspect.exe to view the hierarchy. If I refresh immediately after opening the application, it takes 30s+ to show anything. But If I wait a minute before refreshing, it updates immediately.
I was wondering if someone else had experienced this before, and what might be the cause/solution.
I am running:
Windows 10, python 3.8.3, pywinauto 0.6.8
Sometimes setting an application as an firewall exceptions helps them boot/open faster.
Granting Firewall exception on Windows 10 for an application:
Go to Control Panel.
Click Windows Firewall or Windows Defender Firewall option.
Choose option "Allow an app or feature through Windows Firewall" (on left side).
Select your application in the list or click on Add Another App to find it and add it to list.
After debugging some more, I have resolved the issue, although it's not clear to me what the root cause actually was.
The custom application I'm testing launches a background application as a non-visible console. Testing showed that not running this background application allowed me to conenct immediately. Running the background application by itself would cause the same delay in inspect.exe loading.
The application was a dotnet framework application, that in theory was a console only application, but had code supporting a WPF interface (which was not displayed). By removing the WPF aspects of the project, I was able to build the application as a purely console application, and I no longer experienced the earlier delays.
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.