Somebody used a Windows API call that's been around longer than any of these ham radio programs. It's not Microsoft's "madness", it's a programmer's failure to include windows.h when you make a Windows API call. That being said, I see nothing wrong with this fix either.

Yes, I've run into this before with the QGC application. There we chose to use it for the Windows build, with the proper ifdef's, because it is a documented class for the Windows API and it provides the UI consistency in a Windows build that Windows users expect. It can be used on other platforms as well, it's not proprietary. But when using it on Windows you need to use the windows headers with it.

The major platforms - Windows and Mac - have documented API's to provide the consistency and standardization on those platforms that programmers must adhere to. This happened to be one of those cases. I was rather happy with your fix. I was not too impressed with the original coder that wrote the code and used that class, and then realizing there was a problem, put a "hack" in the code to deal with it. Back at that time, the fix you implemented (or something similar) would've been the proper way to fix it. Or if you want to use it, then include windows.h. You'll notice that our third party code suppliers include windows.h when using Windows API's. So when this was found by formatting the code with clang-format it baffled me as to why it was done that way in the first place. Whoever wrote that original code should've known better. Thanks for finding it and fixing it.

Also, if I was doing the coding on that fix, in the comment I would've noted that this is a documented Windows API and the change implemented chooses not to use it because it wasn't implemented correctly. That way, it informs other programmers working on the code that if they inadvertently use a documented API like that, include the proper headers for it.

And one final comment. On MacOS, there is documented API's for building the Info.plist regarding information strings and versioning. That was not adhered to in the original code and when submitting the app to Apple for notarization causes it to get rejected. I recently fixed that in the versioning change. I suspect we will run into other such issues in the code in the future, probably when we start taking mainwindow apart. mainwindow is probably the biggest kludge in the entire codebase and for a Qt application should've never integrated the UI with the back end. That class is so poorly written hardly nobody can touch it without breaking something.

mainwindow is probably the biggest kludge in the entire codebase and for a Qt application should've never integrated the UI with the back end.

Yes. Actually, for any GUI application, be it Qt or whatever, having application code mixed up with the UI code is a big bold red flag.

That class is so poorly written hardly nobody can touch it without breaking something.

We have to accept our fate that we have to be diligent and careful and will still break things nevertheless. (Part of that fate is also that we will be heroes, though probably rather unsung ones.)

But hopefully, with each touch, the mess will become less messy and more manageable. The beginning is the hardest.

But even a long journey can be completed one step at a time...

Yes. Actually, for any GUI application, be it Qt or whatever, having application code mixed up with the UI code is a big bold red flag.

Yessir. You are right. I suppose when ever we change anything in there, and it's a change that can be broken out into a separate class, we could do it that way one step at a time.