dummzeuch

Wow, I totally missed that. (This still doesn't increase the likelyhood of that particular software ever being used in the US.) Now, if they switched to a sane date and time format, that would be cool. Or did that happen and I missed it too?

In my case it's not Windows 10 but Windows 8.1.

Thanks, but the US is not a market for this program (and probably will never be, but who knows? It's probably as likely as the US converting to metric. 😉 )

I will probably go with "mileage" then, even though that will raise questions whenever some translator stumbles upon it (the next translation will be to Portugese, that's going to be interesting).

No. An Odometer is a device to measure mileage. "Odometer value" or something like that would probably be OK for some usages but not in my particular case (which is the "mileage" of a special type of tyre).

Btw: Your github page says: ##Get started Have a look at my blog posts about TFrameStand Unfortunately that link seems to be broken. http://www.andreamagni.eu/wp/tag/tframestand/ It should probably be https://blog.andreamagni.eu/tag/tframestand/ instead.

I used a similar hack in an earlier version of my program: Wiggling the mouse pointer. While that worked fine under Windows XP, it doesn't under Windows 10 (no idea about Windows 7 and 8). That was the reason I researched how to do it "right". Toggling numlock all the time would drive me crazy.

The Delphi IDE has the quite useful option to add custom entries to the Tools menu. These entries call external programs with some “Macros” that reference the current IDE status, e.g. the currently active project or source file and some of their properties like the output directory or the current editor column and row. GExperts already enhances the Tools Properties dialog by adding auto completion for the file name and the working directory (for Delphi 6 and 7 it also adds support for Drag and Drop, but that doesn’t work for later versions). It has always irked me that there was no easy way to port these custom tools entries from one Delphi version or installation to another. I always had to copy and paste four fields to achieve that. GExperts now adds two new buttons to export and import the current entry: Read on in my blog post https://blog.dummzeuch.de/2019/06/08/new-gexperts-ide-enhancement-export-and-import-entries-for-the-tools-menu/

Only one at a time. There is no API for them and I can't get at the data from the dialog that lists them. It's also not possible to directly modify the registry while Delphi is running, it will simply overwrite the new entries. Also there appear to be two different formats for the registry entries and they reference resource strings in the IDE. It's a veritable mess.

If there are multiple instances of program1 and it always uses the same file name when it starts its own instance of program2. These multiple instances would then all write to the same file. That's a race condition in my opinion.

I would like to remind you that I was asking for experience with the IPC methods: For now I have implemented it with passing a file name as described in my original post. Does this have any drawbacks (apart from the obvisous one: It creates a race condition. I have mitigated this for now by creating a unique temporary directory to place the file in.

From the description it looks to me that atoms are immutable. So how do you propose to return a string from program2 to program1 via a global atom?

If you insist on Github, you can simply create the project there and upload the sources using subversion. Alternatively you could create a project on Sourceforge or OSDN.

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.