dummzeuch

In my last blog post Getting the Windows version, I claimed that there is no way to get the actual version number of Windows 10 without reading the version information of the Kernel32.dll and interpreting it 1. Since then I have been told that there is actually a Registry key that contains the Windows version: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion It has several entries that can be used to get the same version info that the Winver tool displays to the user. On Windows 10 that’s: ProductName ReleaseId CurrentBuildNumber UBR On my test installation they get me “Windows 10 Pro” Version “1809” (OS Build “17762”.”437″) (The quotes denote values read from the registry.) https://blog.dummzeuch.de/2019/04/22/getting-the-windows-version-revisited/ Just to make it clear: The above text is not the full blog post.

In my last post I wrote about the export and import feature for custom Tools menu entries that GExperts adds to the Delphi IDE. I also mentioned that I was thinking about adding a custom clipboard format for copying and pasting these entries between multiple Delphi instances / versions. OK, I did that. GExperts now also adds a popup menu to the Tool Properties dialog with two entries: Copy entry to clipboard Paste entry from clipboard Read on in the blog post https://blog.dummzeuch.de/2019/06/09/gexperts-adds-copy-and-paste-for-delphi-tool-menu-entries/

Yes, I could.

I'm aware of TOSVersion, but it's simply not available in some of the Delphi versions I frequently use. As stated in the blog post, the method(s) described there even work(s) with Delphi 6.

In my case it's because I need access to specialized devices (cameras, lasers, GPSes ... some of it only available in one of our measuring vehicles) to develop and debug software that communicates with these devices. Most of that communication is time critical, so even if that device access could be virtualized, it would only get me so far (I can use remote desktop though, so I don't have to sit in the actual car.) I tried to use the remote debugger, but it was not stable enough. So I ended up installing Delphi on each of the controlling computers. Of course I ran into the installation limit frequently, because those computers just don't survive the conditions they are used in for much longer than 2 years (it's cheaper to frequently replace them rather than trying to protect them.) That's why I switched to a network named license last year. Much more convenient. Of course that's not quite the typical use case for Delphi. Until Microsoft stops supporting your operating system and the corporate IT department tells you to upgrade, because your Windows XP/7/8 is a security risk. And even if that does not happen, keeping several VMs up to date while maintaining backups quickly becomes a major chore. Even with multi terabyte hard disks it still takes time to copy them around.

No, it still works when switching to Europe.

The Online Help says the following about GetMemory: http://docwiki.embarcadero.com/Libraries/en/System.GetMemory What exactly does it mean by "GetMemory is the C++ compatible version of GetMem."? What does GetMemory do that GetMem doesn't? Why and when should I use GetMemory or GetMem? This is the OLH for GetMem: This function is not available in C++. In C++ you can use GetMemory. In case of a typed pointer, you should consider the New and Dispose procedures, which respectively initialize and finalize the memory block accordingly. I can't see any difference. Maybe it's just that one is available for C++ Builder programs, and the other isn't? So for Delphi programs it doesn't matter which to use?

So the description for GetMemory in the online help is wrong: It does not raise an EOutOfMemory exception.

What does the enter key do? Depending on the usual workflow (does the user usually want to view the report? Or does he want to copy or send it somewhere?) one of the other buttons might be a good option. Another frequently required information for further processing is the full file name, so maybe there should be a fourth button to copy it to the clipboard.

That depends: A transient message is fine, a persistent one that I have to click to get rid of it, can be annoying. If it provides the additional options you propose, it might be less annoying. But that's a matter of taste.

Given the following C type definition: /** image pixel layout information*/ typedef enum VmbPixelLayout { VmbPixelLayoutMono, VmbPixelLayoutMonoPacked, VmbPixelLayoutRaw, VmbPixelLayoutRawPacked, VmbPixelLayoutRGB, VmbPixelLayoutBGR, VmbPixelLayoutRGBA, VmbPixelLayoutBGRA, VmbPixelLayoutYUV411, VmbPixelLayoutYUV422, VmbPixelLayoutYUV444, VmbPixelLayoutMonoP, VmbPixelLayoutMonoPl, VmbPixelLayoutRawP, VmbPixelLayoutRawPl, VmbPixelLayoutYYCbYYCr411, VmbPixelLayoutCbYYCrYY411 = VmbPixelLayoutYUV411, VmbPixelLayoutYCbYCr422, VmbPixelLayoutCbYCrY422 = VmbPixelLayoutYUV422, VmbPixelLayoutYCbCr444, VmbPixelLayoutCbYCr444 = VmbPixelLayoutYUV444, VmbPixelLayoutLAST, }VmbPixelLayout; typedef VmbUint32_t VmbPixelLayout_t; Am I right in assuming that the following constants are an equivalent? const VmbPixelLayoutMono = 0; VmbPixelLayoutMonoPacked = 1; VmbPixelLayoutRaw = 2; VmbPixelLayoutRawPacked = 3; VmbPixelLayoutRGB = 4; VmbPixelLayoutBGR = 5; VmbPixelLayoutRGBA = 6; VmbPixelLayoutBGRA = 7; VmbPixelLayoutYUV411 = 8; VmbPixelLayoutYUV422 = 9; VmbPixelLayoutYUV444 = 10; VmbPixelLayoutMonoP = 11; VmbPixelLayoutMonoPl = 12; VmbPixelLayoutRawP = 13; VmbPixelLayoutRawPl = 14; VmbPixelLayoutYYCbYYCr411 = 15; VmbPixelLayoutCbYYCrYY411 = VmbPixelLayoutYUV411; VmbPixelLayoutYCbYCr422 = 9; // is this correct? VmbPixelLayoutCbYCrY422 = VmbPixelLayoutYUV422; VmbPixelLayoutYCbCr444 = =10; // is this correct? VmbPixelLayoutCbYCr444 = VmbPixelLayoutYUV444; I am in particular usure about the ones following those entries with an explicit value assignment, marked with the "// is this correct?" comment above. I think that enums in C work like this: typedef enum bla { zero, // start counting at 0 one, // 1 two, // 2 three, // 3 eins = one, // reset counter to 1 zwei, // 2 drei, // 3 } So, every time a value is explicitly assigned to an enum the current counter is reset. In case that matters: The declaration is from VmbTransformTypes.h, part of the Vimba ImagesTransform library for Microsoft Visual C(++).

OK, so my original translation was correct. Thanks everybody. Regarding using Delphi enums: typedef VmbUint32_t VmbPixelLayout_t; is used in the function and struct declarations. Yes, I could also change that too and use {$Z4} or {$MINENUMSIZE 4} to ensure that the enum size is at least 4 byte (but can I be sure that they aren't larger? (ever?)), but I'm not sure it's worth it. For now I'll simply go forward keeping it a Unit32, since I need something working as fast as possible.

Embarcadero's documentation says otherwise OK, maybe that changed in later versions. I'm sure I tried that and it didn't compile. But all that is syntactic sugar. I need to know about the values of VmbPixelLayoutYCbYCr422 and VmbPixelLayoutYCbCr444.

No, the ordinal values must be correct. These numbers are passed as parameters to a DLL written in C.

Unfortunately that won't compile: Delphi does not allow duplicate values in these enums.

Even if it's not your intention, it's still considered shouting, because nobody but you knows your intention.

Svn also works fine for Github repositories, as long as you don't try to commit or use externals. Also, pull requests don't work. If I remember correctly, the URL is the same.

You might be thinking of my KnownIdePackagesManager Tool for Delphi, but that only handles IDE packages, not component packages. It should be easy to exend it to do that too, though.

I'm afraid recursive hardlinks word result in an infinite loop right now.

As I said: It's proof that it could be done by a plugin. I didn't say it does it. But you could get the source code and that functionality.

It could be done by a plugin, see the cnwizards advanced syntax highlighting. It may even already support it, I haven't checked.

My impression is that there are very few people left from the original Jedi group. I know for sure that I personally stopped contributing when the project moved to Github, but my contributions were merely a few bug fixes, so they don't really count in the big picture.

The CPU sitting at 13% probably means that something is using one core at 100%. So I would not subscribe to this view: Have you tried to disable all IDE extensions to check whether it is caused by one of these?

Just in case anybody is still interested: I have changed the GExperts Convert Strings Editor Expert to allow for prefixes and suffixes for all lines. Example: I want to create a string containing this code: function FindClassForm(const AClassName: string): TForm; var i: Integer; s: string; begin Result := nil; s := 'Some String'; for i := 0 to Screen.FormCount - 1 do if Screen.Forms[i].ClassNameIs(AClassName) then begin Result := Screen.Forms[i]; Break; end; end; Which means: Quote the lines and escape any existing quotes Add a variable assignment as prefix to the first line Add a " " prefix to all lines to indent the whole thing add a " + #13#10" suffix to each line but the last add a ";" suffix to the last line. The result looks like this: s := 'function FindClassForm(const AClassName: string): TForm; ' + #13#10 'var ' + #13#10 ' i: Integer; ' + #13#10 ' s: string; ' + #13#10 'begin ' + #13#10 ' Result := nil; ' + #13#10 ' s := ''Some String''; ' + #13#10 ' for i := 0 to Screen.FormCount - 1 do ' + #13#10 ' if Screen.Forms[i].ClassNameIs(AClassName) then begin ' + #13#10 ' Result := Screen.Forms[i]; ' + #13#10 ' Break; ' + #13#10 ' end; ' + #13#10 'end; '; There is no release for this yet, but you can always get the sources and compile your own dll: https://blog.dummzeuch.de/gexperts-documentation/compiling-gexperts/

The code is now in dzlib (see blog post for links).