Bill Meyer

Cooperative was a great euphemism. There was no cooperation unless the developer got everything right.

May not be possible in a corporate environment.

Like a few THz? 😉

I think you have the relationship reversed, and meant to write that CodeInsight is only operative with LSP. As reported above, the problem is present in RAD Studio 11. No doubt that is why the case cited is marked "unresolved."

Microsoft: Word, Excel, PowerPoint, etc.

When your products mostly have single word generic names, I suppose you can make use of installers which present no meaningful information.

And for me, for data entry. No email arrives, however. UPDATE: Second attempt succeeded.

Since variants 0 and 3 are reserved, then there really are only two variants. But there are still variabilities in Version. I'd wait to see the spec from IBM, and start be determining whether you can use the existing GUID support with some minor string manipulation afterward. Too many unknowns if you haven't seen their spec.

Have you looked yet at RFC-4122? https://datatracker.ietf.org/doc/html/rfc4122 The document you cite only hits a few points. One issue it raises is that of case, but in the small quote from the RFC, it does point out that although the UUID is output as lower case, it is case insensitive at input. Awkward wording, but I would take that to mean that the UUID is to be read in a case-insensitive fashion, whereas "input" could be interpreted to mean "from the keyboard" or other device. The RFC offers an example of a properly formatted UUID: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 It seems obvious that the issue of case should never be allowed to interfere, given that the alpha characters relate only to hex values. As to your question about a library, I don't know whether one exists. But given that Delphi inserts a GUID for you in this form: ['{480BE84A-F629-4A7C-BC94-4FC06A2E03BA}'] Then by stripping off the leading and trailing braces and brackets and converting to lower case, you would have an RFC-4122 conformant UUID which is of the form specific to MS. And for what it may be worth, I think the author made a poor choice enumerating the four types starting at 1, when the RFC lends itself more naturally to a zero-based reference. In the end, I suppose I should respond to your question with "what do you mean by that?" We could argue the semantics of descriptions, but in the end, the GUID conforms - per the RFC - to the MS variant rules, and the UUID subsumes the GUID.

My dislike for braces dates from a time when I frequently used printouts, and back in the day, it was all too easy for some of them to either disappear or be sufficiently unclear as to be missed. I am also not keen on some of the expression operators, but I seem to adapt more easily to those than to the cursed braces.

As many of us are likely to recall from the old forums, a key perspective here is that "developers don't understand marketing." In order to consider making changes, one must first be open to the possibility that the current state of affairs could be improved.

And yet, it is considered a member of the C family. And probably for no better reason than the use of those braces. And the braces are probably my least favorite aspect of that language.

Moreover, C# came along in 2000, and as a .NET language, arguably had no prior existence in any form. Delphi built on the tradition of Turbo Pascal, which appeared in 1983. And C, the root ancestor to C#, had no string type at all.

It would be good to specify your environment a bit. High DPI or ordinary?

I see. But that sense of doom is just a constant.

You have a twisted sense of humor, sir. 😉

Not by that name. What makes it special?

OK, if we're comparing age.... My first computer was an Imsai 8080 , though by the time I got TP 1.0 for Z80, I was running a Z80 with bank-switched RAM. I still have my TP 1.0 manual, by the way. Insert link doesn't seem to be working, so: https://en.wikipedia.org/wiki/IMSAI_8080

I am working on a large project in Delphi 10.2. Friday all was well. Yesterday morning, I found that I could not run the app in the IDE but received a message that a process needed to be elevated. I have checked settings everywhere, I think. I've reverted to code from last Thursday, and the problem persists. However, the issue, whatever it is, is in the VM, as I carried this VM from my home machine to the office, and I see the problem here, as well. EurekaLog makes no report if it. I tried MadExcept, which is not my usual too, and it does report, but what it is telling me is not obvious to me. The most meaningful content in the fairly long report appears to be this: disassembling: [...] 203b5baa call -$548a7 ($20361308) ; System.LoadResString (dbkdebugide250.bpl) 203b5baa 203b5baf mov eax, [ebp-$64] 203b5bb2 push eax 203b5bb3 mov eax, [ebp+$20] 203b5bb6 mov [ebp-$5c], eax 203b5bb9 mov byte ptr [ebp-$58], $11 203b5bbd lea edx, [ebp-$5c] 203b5bc0 xor ecx, ecx 203b5bc2 pop eax 203b5bc3 call -$52938 ($20363290) ; Winapi.PsAPI.System.SysUtils.Format (dbkdebugide250.bpl) 203b5bc3 203b5bc8 loc_203b5bc8: 203b5bc8 05481 mov ecx, [ebp-4] 203b5bcb mov dl, 1 203b5bcd mov eax, [$203687f0] ; Dbkhelper.EDbkError.Create (dbkdebugide250.bpl) 203b5bd2 call -$5291f ($203632b8) ; Winapi.PsAPI.System.SysUtils.Exception.Create (dbkdebugide250.bpl) 203b5bd2 203b5bd7 call -$54af4 ($203610e8) ; System.@RaiseExcept (dbkdebugide250.bpl) 203b5bd7 203b5bdc loc_203b5bdc: 203b5bdc 05483 > mov eax, ebx 203b5bde call -$4d067 ($20368b7c) ; Dbkhelper.CheckRetVal (dbkdebugide250.bpl) 203b5bde 203b5be3 05484 xor eax, eax 203b5be5 pop edx 203b5be6 pop ecx 203b5be7 pop ecx 203b5be8 mov fs:[eax], edx 203b5beb push $203b5c64 203b5bf0 lea eax, [ebp-$64] 203b5bf3 mov edx, 2 203b5bf8 call -$54acd ($20361130) ; System.@UStrArrayClr (dbkdebugide250.bpl) 203b5bf8 203b5bfd lea eax, [ebp-$54] 203b5c00 call -$5496d ($20361298) ; System.@IntfClear (dbkdebugide250.bpl) 203b5c00 203b5c05 lea eax, [ebp-$50] 203b5c08 call -$54aed ($20361120) ; System.@UStrClr (dbkdebugide250.bpl) 203b5c08 203b5c0d lea eax, [ebp-$4c] [...] If I run Delphi as Administrator, it all works. If I run the executable outside the IDE, it works without complaint. So the complaint seems to me to be related to the debugger, but I have not been able to discover what might affect it. Would appreciate any insights.

Sorry, should have said. It is MediaOffice.exe. So unless they "detect" based on the name containing "office", I am at a loss. Also bear in mind that this has worked for months, with that name. Then in June, suddenly, the elevation error occurred. Switched to a backup VM, and had been fine again until yesterday, when suddenly the problem was back. I had pulled no updates, and made no changes at project level. The changes between builds were limited to code in an Excel export module. The error occurs, however, before we reach the first line of code in the DPR. And there are no initialization sections in the project. None, zip, zero.

OK, this is back again. Went through this sequence of actions: Debugging code, find error Exit app Modify code Rebuild and run Throws error: Did some searching, found this an article on StackOverflow which led me to rename the project and rebuild. That one change let me debug again, but if I revert to the original name, the error is back. The persistence linked to the name makes me suspect something in the registry, but searching there has so far turned up nothing useful. Last time I went through this, I abandoned my VM and used a backup. Since this now seems likely to occur again, I really would like to find a way to identify the mechanism behind it. Any suggestions would be most welcome.

Not surprising it would. Can't help wondering what the reasoning may have been for such a default.

Some searching turned up this: http://www.devsuperpage.com/Articles/views/Delphi/Art_1-1078.asp I've not needed to do this, and the code there is more involved, but I would try that as a starting point, and then perhaps you can find your way to a simpler implementation.

Some years ago, I unhappily encountered a monstrous ternary construct in C. It annoyed me most because since I first read K&R a couple of years after it was published, I recognized that the ternary operator was a shorthand which should always be found in very compact constructions. But the real problem with this one was that not only was it huge -- each element requiring horizontal scrolling -- but it was incorrect in handling its parentheses. It was form some code in Visual C++, which compiled without complaint, but when I tried it in BCB++, it choked, pointing out the mismatched parentheses. The great mystery was, what was the actual behavior in the executable from VS?

Refer them to Donald Knuth, who carefully and clearly makes the case for using goto in some cases.