I have a calculator app I've used for many years that I rather like -- OpalCalc. And I've been meaning for a while to try using the Auto-replace idea demonstrated in one of the FAQ videos.
It doesn't work. Nothing I've tried closes the Windows Calculator app UNLESS I use the power menu to choose to reapply the window's opening state -- at which point, Calculator closes as intended and OpalCalc fires up.
I've tried recognition using all three options, with and without a delay: nothing. And yet the logic of it is clearly OK as reapplying the opening state immediately triggers the replacement.
Win11, Toolbox -- current version 6.1.1.1 -- running as admin.
Hi Oblivion.
Can confirm the issue here. It doesn't occur with other apps (only Calculator), so the match must be missing on Calc's initial opening now (it used to work before the latest Win 11 update). I will look into it to see what's going on.
Paul.
Fixed for next release. :) Please try the latest version I emailed you and report back here.
That was quick, Paul! Yes, the update works perfectly!
Quote from: oblivion on December 19, 2025, 01:14:46 AMThat was quick, Paul! Yes, the update works perfectly!
...although I can't make OpalCalc retain the always on top setting. I think that was the case already, though, I just forgot to make sure I was actually setting it and saving the setting while I was testing yesterday. The other elements -- size, position, transparency -- are retained, it's just always on top that isn't. And I've just tried it with notepad in case it's some bit of weirdness with OpalCalc and it looks like always on top isn't retained for notepad either. :(
Okay, will check again. Sorry for the inconvenience.
Fixed for next release. Was an auto-complete typo when optimizing a window's opening state. :(
Quote from: Paul (Lead Developer) on December 19, 2025, 05:22:12 PMFixed for next release.
Brilliant -- thanks, Paul. And we all commit the occasional typo. Remind me to tell you about the time I almost killed 600 hospital PCs with an infinite loop. ;D
Quote from: oblivion on December 19, 2025, 05:44:15 PMthe time I almost killed 600 hospital PCs with an infinite loop
:o Is it a quick story? I love stories.
Quote from: GCRedditor136 on December 20, 2025, 04:42:25 PM:o Is it a quick story? I love stories.
Quick? Not exactly a one-liner but I guess I can try to summarise.
Background: back in 2001, I got a job providing support to a by-then-well-established clinical information system for a hospital.
The application itself ran in a DOS window (or VDM, if you prefer) and was regarded with disdain by the IT department, because it wasn't a native Windows application. (It was written in Clipper using database extensions that made it outperform most SQL-based systems, and was one of the first Electronic Patient Record systems anywhere that was actually popular with the doctors using it. This may have been because it was designed and written by a doctor.)
So, over time, working with the system's author, I added more Windows functionality (mostly by distributing things like image and PDF viewers that the program could trigger as needed) and wrote a launcher for it in AutoHotkey that could control the environment it ran in, tidy up data it left on the host PC for security, and -- crucially -- check for and pull down updates.
The update process was a bit awkward because there wasn't a way to query the program's executable to see what its version was. Also -- you may recognise this if you're reading, Paul! -- the author would often make bugfixes and small changes without changing the thing's internal version number anyway. So I used an Autohotkey function to compare the timestamp of the (network-stored) updated version of the main system or the loaders and other hangers-on I'd built and invoke update routines if required. The idea was to have things update silently in the background rather than ask users for permission.
Which is fine if your coding's perfect. Mine, on this occasion, wasn't. And the loader program loaded, did some stuff, handed control to another program that checked for any required updates (which had already been updated if required by the main loader), handed control off to the first process for a rerun, and the reason this didn't go on infinitely was because I created a file called a semaphore that, if it existed, it would drop out of the loop and run the program the users actually wanted to use. I'm making it sound complicated but it's not, really.
However, I managed accidentally to rename the semaphore in one of the two steps -- so the file the existence of which was being checked didn't exist and couldn't exist so the loop went round forever.
And I was so stupidly confident in my own skills that I released the new version without testing it first.
Fortunately for me, the bug only showed up when the program was initially invoked, and by the time I launched my update, most users were already in and running, so only those people who exited and reloaded found the problem, loudly informed the helpdesk that their software was broken and the screen was flickering in an odd way, I realised extremely quickly what I'd done, fixed it and we only had to abort infinite loops on a couple of dozen machines instead of the potentially 600 that'd have been hit if I'd posted the update early or late.
Quote from: oblivion on January 08, 2026, 02:11:44 AMAnd I was so stupidly confident in my own skills that I released the new version without testing it first.
Never a good idea. Thanks for the story!