Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 03/22/25 in all areas

  1. Not quite. See for instance Ohh...WinUI3 is really dead! - When can we expect the announcement? · microsoft/microsoft-ui-xaml · Discussion #9417 The Microsoft strategy for GUI App development is utterly messed up: WinForms WPF Xamarin Forms UWP WinUI3 MAUI And there is no longer a GUI designer. You have to develop XAML in a text editor. Discussion: WinUI 3.0 XAML Designer · Issue #5917 · microsoft/microsoft-ui-xaml
  2. Sherlock

    How to sign .msix packages

    I have, and that uses an older version of signtool: "C:\Program Files (x86)\Windows Kits\10\App Certification Kit\signtool.exe" sign /v /a /fd SHA256 C:\Win\SignTest\Win64\Release\SignTest\bin\SignTest.msix The following certificate was selected: Issued to: My Company Issued by: Certum Extended Validation Code Signing 2021 CA Expires: Sat Jan 08 12:11:18 2028 SHA1 hash: E7C16794EA23F573DE3EA32B5B564717CE84CC75 Done Adding Additional Store SignTool Error: An unexpected internal error has occurred. Error information: "Error: SignerSign() failed." (-2147024885/0x8007000b) File version is 10.0.19041.685. I'm using 10.0.26100.0 which at least gives a slightly better error message.
  3. Mine https://github.com/vhanla/MineSweeper it is so basic 🙈
  4. Actually, no. Creating and destroying windows is highly discouraged in DllEntryPoint(), see: Dynamic-Link Library Best Practices: Guess where the CreateWindow/Ex() and DestroyWindow() functions reside - in user32.dll ! 0x0EEDFADE is the exception code when a Delphi exception escapes into the C++ runtime. So, what exception type exactly is the TForm destructor actually throwing? My guess is EOSError if DestroyWindow() fails. But a TForm destruction does a lot of things, so there could be any number of reasons why it would fail while the DLL is in the process of being unloaded from memory. Perhaps, if your DLL's TApplication object were already destroyed (or in the process of being destroyed). You should run your code in the debugger and verify that. Your global Form1 variable would not be updated in that situation, so you would have a dangling pointer. One way to handle that would be to assign NULL to your variable in your Form's destructor. But really, this is not the kind of stuff that you should be doing in your DllEntryPoint() to begin with. It would be better to export a couple of functions from your DLL that the loading app can then call after loading the DLL and before unloading it.
  5. NexusDB components are now available in the new 64 bit IDE 👍 v4.7514 adds - 64 bit Designtime Support - Replication (Beta) Find the best Delphi Database at NexusDB
  6. Might this help? https://github.com/RRUZ/tsmbios
×