Sherlock

@Die Holländer That would be my ultimate goal. But this time I actually wanted to "grow" a project with the machine.

My last excursion to Google Gemini was successful at the end, but kinda bumpy still. I started out by asking Which gave me three possibilities ask the user for the key, use hardware keys or DPAPI. It also explained (quite lengthy) what the pros and cons of each solution are. I was kinda looking for DPAPI anyway so I went for that with That resulted in naming the API calls CryptProtectData and CryptUnptotectData stating they should be declared in Winapi.CryptDPAPI.pas or more general in Winapi.Windows.pas. The main advantage being the lack of a password entirely, everything being managed by Windows itself. It then presented me with some example code unit MyDPAPIUnit; interface uses Winapi.Windows, Winapi.CryptDPAPI, System.SysUtils; function ProtectData(const AData: TBytes; const ADescription: string = ''; AForLocalMachine: Boolean = False): TBytes; function UnprotectData(const AData: TBytes; var ADescription: string; AForLocalMachine: Boolean = False): TBytes; implementation function ProtectData(const AData: TBytes; const ADescription: string = ''; AForLocalMachine: Boolean = False): TBytes; and so forth. Of course a first compile with me integrating this into a test project failed, because there is no Winapi.CryptDPAPI. I am a nice person, am I not? Well of course Gemini then said I was totally right, and that indeed everything required could be found in WinAPI.Windows. Then rambled on about why it got so confused, and basically blaming Embarcadero for not consistently placing specific API segments in their own units like has happened with WinAPI.Messages or WinAPI.ShellAPI. It then presented me with a corrected unit ready to be integrated into my project...or so it thought. In its implementation of ProtectData and UnprotectData it used a constant for a specific flag, and that did not go over well with the compiler: Here is what it said then 😄 It then fixed the unit by defining the needed constant correctly. But alas, more errors incoming. I'm still trying to be nice and perhaps lead the machine to realize its own mistakes 🙂 Yeah, it did not react to that slight hint but gave me a crash course on DPAPI. Only after I wrote basically rubbing its nose in the mess, it finally noticed and responded accordingly OK, I thought, that looks good. But it took a bad turn quickly yet again, because it continued with the following and provided me with a "revised" version of the unit where the only correction was more comments, and the constant was now called CRYPTPROTECT_LOCAL_MACINE_FLAG. Oh, goody. Now it really should work, but I didn't bother with a test compile, I was still feeling merciful and wrote I'm guessing by now it is trying to get rid of this issue as fast as possible, because the explanations and excuses are getting shorter and lamer Well, d'uh! So finally it comes up with the perfect reason: And follows up with the perfect solution for the home run: Note the proud addition of the checkmark, so this must be official... it even updated the entire unit. Now it must be right.... but wait, how did this get started again? I'm getting pretty good at shattering this machines dreams. I believe it's on to something here This actually sound correct, so I gave the revised unit a go. And it worked as expected. So that was about an hours worth of work, then had a lunch break and came up with some ideas for improvement. So with renewed strength and the feeling of being on the home stretch I wrote It obliged gladly and even provided me with a sample snippet of how to call this glorious code, which it also explained in depth. Actually this could be a nice side effect of AIs, if one takes the time to really read all that jibber jabber. Buuuuuuuut, again, the unit would not compile because how the AI thought TFileStreams needed to be handled. (I'm already out of patience...this short into the second half, oh my) It then went on and on and finally concluded that this wasn't even necessary because of how TFileStream.WriteBuffer takes care of that automatically. So that was needed to be done was to remove these erroneous calls to inexistent methods...Done, the newly improved unit was presented with a nice remark at the end Yeah, we'll see about that, I have more nuisance to test you with Prompt answer You see that too? Now it's just buttering me up! I sense troubles ahead. To my surprise, the new version worked right away. So I got bold Just that one method...but Grrr...at this point I was happy with the one change for the Protect method, and ignored the Unprotect. Copying only parts of the code now. It worked. Again I was provided with samples for calling and quite extensive explanations on the whys and hows. A neat learning experience I completed by asking some questions concerning this technique and security aspects (i.e. could one know how this file was encrypted?)) and possible issues when running this in a Citrix environment. I feel the answers given where quite good and sounded altogether correct. All in all this has been a pretty cool experiment with the free version of Google Gemini 2.5 Flash. I know there is a Pro version, but I'm not yet ready to spend money on that. Please note I did the session in German, so some translation errors might have slipped in either on my side or the AIs. The entire session can be viewed here: https://g.co/gemini/share/a6d5936220bf

I'm kind of baffled that some folks suggested to do this with HTML....does that compile into a standalone application nowadays, not requiring a browser to run? I mean, the background is supposed to be a desktop, isn't it?

Just to clear and sum up: The error is in the 414 lines of code above this totally fine function. So, until one of the following two things happens, this will turn in to a merry game of guessing: 1) You provide us with the top 414 lines of code 2) You let your IDE format the code and discover formatting is "out of whack" beginning somewhere above line 415, and home in on the problem yourself In any case, I do hope you will provide us with the solution to this riveting riddle.

Rand is OK, but I'm a more modern, WordStar kind of guy. Just love me my WordStar diamond, and loved Delphi for incorporating WordStar shortcuts.

If you are a current subscriber to Delphi, you should have received an invitation to Beta test....

Just as a side remark: macOS is a desktop OS as well. And it has a quite comfortable market share in the US private and commercially, in Europe however mostly in doctors offices. Though the Apple silicon piqued the interest of many a business.

@ChrisChuah Should be pretty straight forward...

Any helpers installed? Such as GExperts, cnPack or MMX?

It works for me as well. Just sayin'...

There is an iOS simulator via XCode available on the Mac you'll need to package and sign the app anyway. But if you don't want to buy a Mac (Minis are quite cheap though), you can rent a Mac online via services like MacInCloud, MacStadium or OakHost just to name a few.

You might consider adding scanning exemptions. Folders, that should not be scanned, because of high performance penalties. But you should keep an eye on those folders by other means.

Except carrying the rig around. *SCNR*

So I built a list of data grouped by devices where this data came from. Each device gets his own header in a TListView followed by its data. Pretty simple and straightforward. Now those lists may get long in total but also per device so I would like to be able to click on a header to collapse its list of data. I'm pretty sure VCL.TListView can do that. FMX.TListView...not so much. At least not that I'm aware of. I'm already having a hard time at getting the click event from a header. All TListViewItems with Purpose set to TListItemPurpose.Header sadly wont fire the OnItemClick event. Did I overlook something or other in the documentation? Anybody have a suggestion as to how this can be accomplished. Thanks in advance.

To expand (or perhaps reiterate) that answer: Components are not installed (or even bought) just to have them. If during programming you discover you would benefit from a ready to use component for some functionality over writing it yourself then you should consult the internet or perhaps this forum on where to find such a component. Event hen, if it is a commercial component, you might want to calculate the cost benefit over writing it yourself. Furthermore it is most often preferable to have sources for components to ensure their use over time.

I think it would be fair to say that Windows on ARM is not for legacy environments. It is intended for new mainstream devices. So no immediate support for decades old printers and other old hardware should be expected. However(!) as soon as it gets more traction I expect that to change.

You should rather read that as "they will open up the next major construction site as soon as there is money and manpower available, and it will take several releases until it is usable"...and even that should be taken with a grain of salt.

@oeko11 In English please...

Perhaps this will cause the DOGE to rethink their plans for COBOL (*) ...as a matter of fact I'm sure of it. (*) https://www.wired.com/story/doge-rebuild-social-security-administration-cobol-benefits/

So, I've been kept from doing things by this little, trivial problem. I've been trying to sign an msix package for days now, and am getting nowhere. I can sign Win32 and Win64 executables just fine, Delphi will create unsigned msix packages just as good. But I just can't for the life of me sign an msix. I always get the same error message, it does not matter, if this package contains my application or just a simple dummy, or if it is win32 or win64: "C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\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: This file format cannot be signed because it is not recognized. SignTool Error: An error occurred while attempting to sign: C:\Win\SignTest\Win64\Release\SignTest\bin\SignTest.msix Number of files successfully Signed: 0 Number of warnings: 0 Number of errors: 1 I even built the msix externally with the makeappx tool from the SDK, that works just fine (as it should, Delphi uses it as well), but in the end...same error as above as soon as I want to sign the package. The AppManifest.xml is in good shape, syntactically and content-wise. The only assets are two png Icons that can be read just fine. The executable itself can be signed with no trouble at all. What am I missing?

OK, so good news: I finally got it. Thanks to "msix hero" an OS tool specifically made for everything msix. https://github.com/marcinotorowski/MSIX-Hero. It just signed my little test project right away. Now I can go on working. Thanks everyone for your contributions and support.

That site has been up for a week. You can work fast with Delphi, but you can't work magic.

How does this construct work on Windows? As expected?

Oh, that sounds great. For a test run, I downloaded the installer and am quite overwhelmed by the further needs (service user, SSL-certificate, Server) to run the "server". For a small test if my msix could be signed by this, it seems quite the overkill. 😞