dummzeuch

Shared memory, a named pipe, sockets or even a file comes to mind.

Following up on I am trying to use the 64 bit dll from a 64 bit program that then executes a 32 bit program and controls it via stdin/stdout/stderr redirection. While this works fine (after I realized that I need to call Flush after each Write call otherwise it might be stuck in the 128 byte internal cache), I wonder how I am going to debug the 32 bit executable. I remember seeing a debugger option to also debug external executables started by the executable being debugged, but I have no idea whether that was in Delphi or some other programming environment I used years ago (Virtual Pascal?) and I can't find it in Delphi. Also I doubt that this would work for 64 bit programs executing 32 bit programs. Just to be clear: I have got a 64 bit Delphi program that starts a 32 bit Delhi program, sends input to it via stdin and receives output from it via stdout and stderr. I want to run that 32 bit Delphi program in the debugger. The only way I currently see would be to attach to that program after it has been executed. But that's rather cumbersome. Hm, maybe I could reverse this: Have the 32 bit programm run in the debugger and have that start the 64 bit program and communicate with it via stdin/out/err ...

Interesting idea ... [testing it] ... doesn't work though. The 64bit programm configured as host application doesn't get started at all. The debugger starts the 32bit program but without input/output redirection. Maybe this only works for DLLs and packages?

Wich will result in multiple expensive calls to GetLocationInfo...

That's not quite true. They will usually allow you to continue your subscription if it run out not too long ago. But of course starting with the date it run out. Also, there are some special offers from time to time, where you can save part of the price for a new license. But for a while keeping the subscription active has been the cheapest way to update (if you can call that "cheap"). And every time you have to remove "platinum support" from the order. The one thing that has annoyed me the most, is that you need an active subscription to even download an install bugfixes.

Is there a way to call a 64 bit dll from 32 bit Delphi code? As far as I know that's not possible, but I have been wrong before. I am aware of this Article on Process Interoperability on Learn Microsoft.com. And there is Using 64-bit DLLs in 32-bit Processes with Out-of-process COM which is about C# and WoW64Injection: Loading a 64-bit DLL in a 32-bit process which probably won't help at all. (Hm, maybe this should have gone to RTL + VCL ?)

My experience is definitely different: Changing an include file does not force the units that include it to be recompiled.

Move the code to an empty unit and try to compile that one. If it still does not compile post the full code of that new unit here. I think the problem is not in the code you have shown us but somewhere before that.

No, simply two monitors with different resolutions (and different scaling): Just to make this more difficult, monitor 2 (1920x1200 scaled 100%) is the main monitor, so all positions on monitor 1 (3840x2160 scaled 125%) are negative x (-1 to -3839) and some are even negative y. I always put the IDE on the right 2/3 of monitor 1, that's why saving and restoring desktops in Delphi IDE's is broken on my setup since Delphi 11. Also this is the reason that scaling in the Delphi IDE is broken on my system (and my home grown scaling in GExperts is very difficult to do and still has some glitches).

AI will feature prominently in the release announcement, that's for sure, but from what we have seen in Marco Cantu's blog posts so far there is definitely more.

Yes, definitely. Negative positions are totally normal, if a form is on a monitor left or above the main monitor. And the code is definitely broken, because it uses "with screen do". Using screen isn't necessarily wrong though as it should include all monitors, but it assumes that the visible area is a rectangle, which may not be the case (it isn't in my setup).

According to https://www.advdelphisys.com/help/ads_keys_u.html Ctrl+O+C starts column selection mode or with the mouse Click+Alt+mousemove (https://docwiki.embarcadero.com/RADStudio/Sydney/en/Default_Keyboard_Shortcuts)

I wonder whether there will be a code formatter that supports this. Given that they deprecated the existing one since Delphi 11, I somehow doubt it.

There is always the return address on the stack. Which you can get by calling ReturnAddress But I guess you don't want an address but a function / method name? JclDebug offers some functions for that: https://stackoverflow.com/questions/1301254/how-to-get-current-methods-name-in-delphi-7 Or as described here:

Excactly, why don't you? These people know about this detail? I would have expected that they had never seen any Pascal code and even if they did, that they wouldn't have noticed the way variable declarations work there.

If I remember correctly there is no way to access the compiler messages through the NTA because the output goes to a modified VirtualStringTree (but if you find one I would be very interested indeed). But the OTA might give you that access, I haven't checked.

If the NTA offers advantages to your plugin you can always add that later. Whether that's the case depends on what your plugin does.

I hereby apologize to Embarcadero. They replied on the same day to our general purchasing account (which was correct because that is the email address used to register the licenses). Somehow I must have missed that reply several times when I looked there. And I managed to fix the problem too, even though I am still not sure what I did wrong the first time. And thanks to Devid Espenschied for clearing that up.

I filed a support ticket with Embarcadero two days ago regarding a problem with license hosting on the ELC. I haven't heard from them yet. How long does it usually take them to get back on such issues? Previously I got an answer from Embarcadero Germany with a similar problem, but since Matthias Eissing is no longer with us, hopefully somebody else has taken over that job.

Thanks for the reminder. I had totally forgotten about Devid and have now contacted him directly. (You might want to remove his email address from your post to prevent spam.)

So far most of the libraries only needed very little changes when a new Delphi version came out. Mostly it was adding a new compiler version to a central include file. In the case of the JCL that file would be jedi.inc. Hypothetically somebody else might have done that already when you join a beta program and posted a link to the updated version in the also hypothetical internal communication channel. (Hypothetically because 1. I am not in the current beta (Haven't received an invitation yet) 2. Even if I were, the NDA would prevent me from telling about it, but it stands to reason.)

I still don't understand the problem of detecting whether dcc32 of a CE installation can compile anything. What does it do if you give it an empty .dpr file to compile from a cmd window? Does it just silently fail? No error message? But even if that is the case, you could at least try to compile said empty .dpr file and check whether an executable is created. Not quite an elegant solution but it should work.

Does the executable dcc32.exe exist in that case? If not, there's your answer. If yes and it only outputs an error message or something, you could do exactly that: Call it and check for that error.

Some Delphi IDE versions have an annoying bug with the toolbars that makes them unusable if you customize them. If you have seen this problem, you know it, if not, congratulations! Unfortunately I am one of the people who experience this problem and it annoyed me so much, that I added a workaround to GExperts. ... read on in the blog post.

And that was most likely the reason. The compiler only compiles units that have changed. Changing the include file does not change the units. To ensure that a unit is recompiled after a change to an include file, you must do a complete build of the project(s). The same applies to defines set in the .dproj file btw. Changing them does not trigger a complete rebuild. If you want to be really paranoid about this, delete all units from the unit output path. This ensures that every unit will be recompiled. I do that once in a while.