dummzeuch

They must be rather desperate.

It most certainly is. I've never been surprised by how cheap a product is, when I had to ask for a price. On the other hand it's sometimes worth to ask for a discount when the price is published.

Fixed. I forgot to call InitDpiScaler in the constructor.

Just so nobody gets disappointed: That expert is only available for Delphi 2009 and later. Delphi 2007 and older are lacking the OTAPI support for it. Here is the original blog post.

If I remember correctly there is a splitter between the edit memo and the inherited list. But I think the position isn't saved (yet). Is that screenshot from the Delphi 11 version? On a monitor with > 100% scaling?

I call GExperts experimental because I don't want anybody thinking that it has been thoroughly tested. Way back, when there actually were several people working on it and many more testing it, there were stable releases. Today I'm the only developer (apart from some very few contributions from others, for which I'm very grateful) and my time is very limited. I simply can't test with all Delphi versions, so only those that I use regularly (currently 2007, 10.2 and some XE2) could be called kind of stable.

If I hadn't seen this post before reading the previous one, I wouldn't have recognised the sarcasm there either.

That's no alpha symbol in your template, that's a lower case sigma. (Or it's the forum software that broke it.) Care to share those templates?

It's DxGettext. If I disable translations, renaming the file works with SysUtils.RenameFile, with the Explorer and also with the Rename command. Man wird alt wie 'ne Kuh und lernt immer noch dazu.

That's really odd. I just tried it because I couldn't believe it: VCL-Application with a form and a button b_Rename and the following code: procedure TRenameExeTest.b_RenameClick(Sender: TObject); begin RenameFile(Application.ExeName, Application.ExeName + '.old'); end; Works as expected or rather as not expected by me. Now I wonder why the Explorer and the Rename command cannot do this. Interestingly, after the program has renamed its own executable, it's possible to rename it back using the Explorer. And even more strange: This program can be renamed with the Explorer while its running. The one I tried first (last post with the screenshot) could not. I wonder what causes this. Maybe it's DxGettext that keeps the file open because it accesses the linked in translations? Or JclDebug accessing the jdbg information in the file?

Hm, neither Explorer nor the rename command on the commandline can rename an executable that is currently running, so I have so far assumed that's not possible.

That's actually a good thing: It's easily reproducible. Are you using any plugins? If yes, disable them and try again. Does it still happen every time? If yes, it's the IDE and you probably can't do anything about it (apart from reporting this bug to Embarcadero, of course). If not, enable these plugins one by one and every time try it again. This should tell you which plugin is causing the trouble. In that case report the bug to the plugin maintainer.

Are you sure that is what it does? As far as I know only DLLs can be renamed while in use, but not EXEs (*1). (*1: Unless the EXE is located on a Samba-Sever share but then it can only renamed directly on the Unix/Linux box and if you do that it will come back to bite you.)

I just spent some time testing ChatGPTs ability to "understand" and explain Delphi source code. The results were actually quite good. I asked ChatGPT "what’s wrong with the following Delphi code?" function IsoStringToDateTime(const ISODateTime: string): TDateTime; const ISOShortLen = 19; ISOFullLen = 23; var y, m, d, h, n, s, z: Word; begin // ISODateTime should be in one of these formats: // YYYY-MM-DDTHH:NN:SS, YYYY-MM-DD HH:NN:SS // YYYY-MM-DDTHH:NN:SS.ZZZ, YYYY-MM-DD HH:NN:SS.ZZZ if (Length(ISODateTime) <> ISOShortLen) and (Length(ISODateTime) <> ISOFullLen) then raise EConvertError.Create('Invalid ISO date time string: ' + ISODateTime); y := SysUtils.StrToInt(Copy(ISODateTime, 1, 4)); m := SysUtils.StrToInt(Copy(ISODateTime, 6, 2)); d := SysUtils.StrToInt(Copy(ISODateTime, 9, 2)); h := SysUtils.StrToInt(Copy(ISODateTime, 12, 2)); n := SysUtils.StrToInt(Copy(ISODateTime, 15, 2)); s := SysUtils.StrToInt(Copy(ISODateTime, 18, 2)); z := StrToIntDef(Copy(ISODateTime, 21, 3), 0); // Optional Result := EncodeDate(y, m, d) + EncodeTime(h, n, s, z); end; and also "What does the following Delphi function do?" function FileSizeToHumanReadableString(_FileSize: Int64): string; begin if _FileSize > 5 * OneExbiByte then Result := Format(_('%.2f EiB'), [_FileSize / OneExbiByte]) else if _FileSize > 5 * OnePebiByte then Result := Format(_('%.2f PiB'), [_FileSize / OnePebiByte]) else if _FileSize > 5 * OneTebiByte then Result := Format(_('%.2f TiB'), [_FileSize / OneTebiByte]) else if _FileSize > 5 * OneGibiByte then Result := Format(_('%.2f GiB'), [_FileSize / OneGibiByte]) else if _FileSize > 5 * OneMebiByte then Result := Format(_('%.2f MiB'), [_FileSize / OneMebiByte]) else if _FileSize > 5 * OneKibiByte then Result := Format(_('%.2f KiB'), [_FileSize / OneKibiByte]) else Result := Format(_('%d Bytes'), [_FileSize]); end; The answers will surprise you. And these were the shocking answers. The answers were actually quite interesting.

Which only goes to show that the definition of "intelligence" is still very difficult, or at least is used very narrowly in the context of "artificial intelligence".

You could aks ChagGPT to look for bugs in these. 😉

I wasn't aware that I did that. Did I?

I didn't expect it to perform that well, in particular the descriptions it gave for what those functions do. I found that interesting. These were simple tests where I knew the correct answers. It might be helpful in cases where I don't know the answers. Our possibly not. The code I'm usually dealing with is much more complex than a simple function. But you never know. Regardless of whether it will ever be helpful, I had some fun.

It has been in the source code for quite a while and some few people and I have tested it, but I didn’t tell anybody else about it: There is a new expert in GExperts for editing the current project’s unit search path. It looks like this: (read on in the blog post)

I have just applied patches that are supposed to fix some Unicode issues with Russian characters. These apply to the following experts: Macro Template Locate/ Move to matching delimiter Previous / Next Identifier reference My tests so far have shown no changes on how these work on my source code, but I usually don’t use any special Unicode characters and in particular no Russian characters. So if you want to help out, whether or not you are using Unicode characters anywhere (for identifiers or within strings or comments) and especially Russian characters, please compile a new DLL from the current source code an test whether anything has been broken (or fixed). (Original blog post with links)

It not merely compiles but works as expected.

Hm, you declared K and V as class. An oversight? Changing this to TObjectDictionaryWithDuplicateObjects<K; V:class> (semicolon instead of comma) made it work (or rather compile) for me.

I'll try that dictionary + object list approach tomorrow. It's actually much neater than the sorted object list I was thinking about, and should also perform better, but that's not a real concern as I expect only a few dozen entries for the current need. But on the other hand, I'll probably start using this in a lot of other cases in the future.

Hm, shouldn't freeing the dictionary automatically free the object lists stored in it, which would then in turn free the objects stored in those? So there should be no need for the MyFreeObjectsFromList procedure, or am I overlooking something?