I have installed kMyMoney on Windows 10 and everything was smooth. I'm now trying to switch to Windows 11 on a new machine. I installed from kmymoney-5.1-1236-windows-msvc2019_64-cl.exe. The first time I tried to start kMyMoney, I got messages about kmm_*.dll files. I found them in the kMyMoney program files directory and added the \bin directory to the path. I got by that but not I get a message about "not QT Platform plugin could be initialized." I see QT5*.dll files in that same \bin directory. What more do I have to do to find and initialize the plugin so I can open kMyMoney? I searched the FAQs and this forum but didn't find an answer.

I don't run Windows, so I can't be sure, but it is possible that when you changed your PATH variable, it is now finding a wrong version of some dll before the right one.
The first thing I would try is to use the most recent windows version, which looks like kmymoney-5.1-1514-windows-msvc2019_64-cl.exe. (from https://binary-factory.kde.org/job/KMyM ... /artifact/). It might be worth uninstalling the current version first, and setting your PATH back to its previous state.
If you still get the same error, try launching from a command line to see if there is any more useful output.

ostroffjh, as I stated in my post, that is the name of the installation I used. I'm not sure it came from that URL so I'll download from there and try a uninstall/reinstall. The idea of finding a different DLL first is interesting but I don't think it's a fruitful line of thought.

Is there a place in kMyMoney configuration specs where the QT plugin is named? I'm not sure how to find out what DLLs are being loaded so it would be very difficult to check.

Why don't you think it's worth checking if the right dll is found first? While I'm not certain that is the problem, it should be easy enough to check.
My understanding is that the Qt Plugins are part of the underlying Qt installation, not the same as the KMyMoney Plugins. Same term, different beast. As the KMM install file (the exe you run to install KMM) contains all the necessary Qt libraries and other dependencies, it really shouldn't have any problem finding them, which is why I wondered if another copy, possibly of different version, might exist on your system. I am not completely sure, but I don't think the location of those Qt dlls is in any config file. When a program looks for a dll (remember, I admit my Windows knowledge is a bit sketchy) either the full path is specified in the program, or just the name, and the system has a list of directories to search (and I don't think this is exactly the same as the PATH used for finding exe files.)
However, I do believe (if the new version also doesn't work) running from command line might show some useful information in the output.
Back to the beginning however, can you provide the exact wording of the various error messages. Sometimes that helps us find where they are coming from, and why.

Should be easy enough to check how? There is no way that I know of to get a list of DLLs loaded or even used by a program. Also, I have never run a Windows program from the command line except for utilities like chkdsk, memchk, and regedit. That said--

I have never installed QT on either system. On both, I installed pre-compiled binaries of KMM from the installation file kmymoney-5.1-1236-windows-msvc2019_64-cl.exe. On Windows 10 it worked and I was able to run the program without making other changes. On Windows 11, I had to add "C:\Program Files\kMyMoney\bin" to the path and, apparently, I would have to do something else.

I said I would uninstall and reinstall KMM and I did, but this time I ran the installer as an administrator and it worked. I can now run KMM. As a result, I can't give you the exact wording of the error because I no longer get it.

Thanks for your help. My takeaway is to always run installation software as an administrator in Win11.

I have a kUbuntu installation along side my Win10 on my old machine. Having some experience trying to convert from MS Money Sunset using QIF files, I want to find out how to create the ability to compile KMM from source. An accounts that the importer creates are dated with the current date. That assumption GUARANTEES there will be a date problem for the user. The transaction being imported has a near perfect chance of having a post date before today. Maybe I can add to the project by correcting that one simple thing and then see what else I can do.

The "msvc2019" in the installation file name makes me suspect there is a Visual Studio project for the program. Do you know if that's true?

Now that you have the new version working, I suspect that as a non-admin, the dlls couldn't be installed where they expected to go, and so the installer put them where it could, thus the need to modify the path. Since your solution was to intall as an admin, I agree that the problem was not finding the dll, and not finding a wrong version. Since I don't use Windows, I would have to search for details, but there are tools available which check an exe file to be sure all the dlls it loads are actually available, and they can then check for the dlls needed by the first set of dlls, and so on.

As for your migration, I believe that the importer will work for dates earlier than the account creation date, and the next time the consistency check is run, it will adjust the account opening date to be early enough for existing transactions. Another option would be to run the importer, and if the transaction imports fail, the account creation should have succeeded, and you can adjust the opening date for the account and rerun the import.

Also, although you no longer need to do so, running from command line is done just like the other commands you mentioned. Open a command prompt (CMD in Windows 10? I don't know the name in Win11) and type kmymoney. If the actual kmymoney executable is not on your PATH, then you may need to type the full path to it (C:\\path\to\the\file\kmymoney.exe".)

Although I have done it in the long past, building KMM on Windows is beyond me. Remember, since all dependencies are included in the install exe, they all have to be built first. Yes, I believe msvc2019 is used in the process, but you need all the other dependencies also. Perhaps one of the developers who deals with the Windows builds will add some information on what is actually necessary. Building on Ubuntu would be easier. In either case, if you need help building from source, I would start a separate thread for that.

Jack

The windows versions created on the KDE CI infrastructure are using a Python based tool called Craft. AFAIU, it was initially based on the Gentoo's ebuild. How it is used for Windows is explained on a separate page. Even though it uses the MSVC19 compiler it is not using VisualStudio or VSCode (which I cannot recommend to use anyway). One of the devs is also working on a statically linked version based on vcpkg.

Another dev initiated a cross-compiled version using mingw. It is build using OBS (Opensuse Build Service). This one supports the AqBanking online plugin which is not supported by the version build on KDE CI infrastructure because it does not support autotools builds. Some details and links to it can be found on the snapshots page.

Regarding your comment on the account opening date: this maybe true if the QIF file does not have an opening balance transaction that contains a date.

Sometimes security software can be too aggressive. Before you run the Windows KMM setup, you should bring up the Properties of the .exe and Unblock. Similarly, if you use the Windows .7z version, Unblock it before extracting. Also, if your antivirus is Windows Defender, you might add an exclusion for KMM.