dummzeuch

The GExperts formatter definitely has some serious shortcomings, in particular when it comes to supporting generics. Just have a look at the tickets on this topic on SourceForge.

It definitely should work.

According to Matthias Eissing (Embarcadero Germany) it's based on Delphi 11.3 pro including Patch 1. The usual restrictions apply: No command line compiler, license valid for 1 year, restricted to non commercial or "low commercial" use. Announcement in the German Delphi Praxis: https://www.delphipraxis.net/212933-delphi-community-edition-11-verfuegbar.html#post1521576 Announcement on the Embarcadero website: https://www.embarcadero.com/products/delphi/starter

Use a normal OnClick event and check whether the Ctrl key is currently pressed. That's the only way I know. function IsControlKeyPressed: Boolean; begin Result := GetKeyState(VK_CONTROL) < 0; end; Source: https://tips.delphidabbler.com/tips/45

GitHub has announced (in January 2023, but I only just saw it) that they will remove Subversion support in January 2024.

Odd. All they ever ask me to implement is a working solution in as short a time as possible (finished: Yesterday) When they get it, they sometimes are actually content with that, but most of the time they then start complaining about missing features, stability, performance, UI ...

Even easier: Just continue using the current, working solution. I was just giving an example for a possible use case.

Out of the top of my head I have at least one idea: Our internal programs all use a configuration frame class that, when created, hooks the form's OnClose event so it can save the configuration when the form is closed. If that event is already assigned, it needs to call the original method. So a multicast event would have saved some code. But unfortunately this implementation won't help because it doesn't magically make OnClose a multicast event.

FPluginTimer.Enabled := False; if (Assigned(FPluginTimer)) then FreeAndNil(FPluginTimer); That part doesn't make much sense. Either FPluginTimer is assigned, then you can simply FreeAndNil it, or it isn't, then the first line will cause an AV. I don't really like the fact that it needs to use a TTimer, but if there is no other way to be notified when the the interface becomes available... You also should put all that into IFDEFs because the code won't compile with anything earlier than Delphi 11.

Unfortunately this will only work with Delphi 10.4 and higher, because it uses Custom Managed Records. But it's still a very interesting implementation which could be ported back to older Delphi versions that supports generics with some hacks, or even older (down to Delphi 2007 or maybe even 2006) by replacing the generics with custom event declarations. But of course that would make it a lot less convenient.

I have just released version 0.0.6 of my Denkzettel Companion tool. It is available from OSDN. This version fixes several bugs ... Read on in the blog post.

Nowadays single threaded CPU performance doesn't really improve that fast. And even if it did, do you really propose to replace all computers in an organisation, because one program is too slow? It's much better to improve the software, especially make it multithreaded, because that will benefit everybody at once, including those who actually get a faster computer. And often it's not even possible to solve a performance bottleneck with hardware. It might be in some area that is intrinsically slow. Ok, in that case, compiler optimisation won't help either. But that's a low hanging fruit: If the compiler creates better code, all programs will benefit just by recompiling them. On the other hand: There are so many awfully slow programs around, that even without any optimization and with full debugging enabled, a reasonably well planned and written Delphi program would outperform most of them. I'm currently on vacation, but before I left, I was analyzing a tool that comes with hardware with a 5 digit price tag, which not only has a dreadful user interface but is also slow as hell. I plan to replace it with a Delphi program, because everybody in the company who came in contact with it, hated it on sight. To be fair: It's the frontend part with the UI that sucks, I won't be able to replace the backend, that does the actual work. And I will of course only implement those parts of the functionality we actually use.

Performance can be an issue, but most of the time it's not really the performance of the generated code but the wrong algorithm selected by the programmer or a faulty implementation of that algorithm. Only after the best algorithm has been selected (and properly implemented) the optimization of the compiler becomes an issue. I have had several performance bottlenecks that were solved by simply turning on optimization (which I usually leave turned off due to it not making any difference and sometimes creating issues). But once you get to manipulating large amounts of data that reside in RAM, the poor quality of the compiler begins to show. But in my experience these situations are rare.

I remembered and tried it: Works fine with a memo too. So your problem is not the send command but something else in your AutoHotkeyScript. As I said before: I still suspect that to be the case.

It catches the combination of the AltGr (the Alt key on the right hand side of the keyboard) with the given character keys and sends some text to the active window. E.g. it catches AltGr+{ and sends an upper case U umlaut. I use this to get German umlauts on UK keyboard layout by pressing AltGr + the key which on a German layout would be the umlaut in question. Some other key combinations are used to send not just one character but a string starting with the Unicode character for an emoji. These are status strings for WebEx, because that brain-dead UI keeps replacing my custom German strings with the English defaults. (I hate WebEx, but the alternatives don't seem to be much better.) As far as I understand it, your script does something similar. I haven't tried a memo, but I'm pretty sure it will work there too. I'll try to remember tomorrow to test it.

The following AutoHotkey script works fine for me in a Delphi 2007 VCL program: <^>!;::Send ö +<^>!;::Send Ö <^>!'::Send ä <^>!@::Send Ä <^>![::Send ü <^>!{::Send Ü <^>!-::Send ß <^>!h::Send 🏠 Homeoffice <^>!p::Send 🍴 Pause <^>!f::Send 😎 Feierabend (The Unicode characters in the last three of course don't.) I also tried a Delphi 11 VCL program. There everything works as expected, including the 3 Unicode strings. So the Send command isn't the problem. Which means it probably is the Windows key you are trying to use as a trigger. Did you try my suggestion:

VCL TEdit and TMemo are just wrappers around the Windows Edit Control, so they should work as any other edit control. If they don't, we need so see the code you use for sending the text to these. But maybe it's something else altogether: Maybe your script doesn't get called because these key presses get intercepted by something else? To find out whether that's the case you could add some debug code to your script that eg. plays a sound or shows a dialog.

Works fine for me with http. With https I get a warning that the certificate is for a different domain. And if I force it, it then goes to that domain?! WTF?

Both are easily available through the file menu, so the welcome page is of very limited use even there. Hm, wasn't there also a "Favourites" panel?

Delphi is dead. Has been at least since 2003. Back then, everybody said that Visual Basic had killed it. Later it was C# and before that it was Java. Ok, on a more serious note: Looking at the state of third party libraries and components, it looks a lot deader today that in the 1990s, but a bit more alive than 5 years ago. Looking at the number of websites that mention Delphi and the number of questions about it on StackOverflow, it is certainly still declining. On the other hand, a lot of things are happening and have been happening around it lately. Embarcadero seems to be a bit more active improving it. And even here on Delphi Praxis some new people have shown up. But of course, Delphi is dead, compared to any of the main stream programming environments.

I'm currently trying to reverse engineer a tool that consists of a frontend with a really dreadful GUI and a command line program as backend, which is called by that frontend and does the actual work. The idea is to write my own frontend that does some additional preparatory work, then calls the backend and … Read on in the blog post.

But quite difficult to reverse engineer. At least compared to the backend just being started with command line parameters. Actually I'm thinking about also tunneling stdin/out/err with the tool. Stdout is actually used by the backend to pads status information back to the frontend.

Hm, where did my answer with the code example, that I posted this morning, go? I'm sure I pressed submit before closing the browser ... Edit: OK, seems to be gone. Not sure what happened @programmerdelphi2k In case your answer was addressed to me and wasn't meant as a joke: I didn't mean to accuse you of anything. Your code is totally different from what I posted anyway.

Exceptions won't work inside the FormCreate method, but if you move that code into the Create constructor you could simply call SysUtils.Abort (or raise any other custom exception). Note though that this will immediately calls the destructor, so make sure that destructor works with a partially initialized instance. I never use FormCreate (or FormDestroy for that matter) but always put the code into the constructor / destructor of a form. This saved me from the OldCreateOrder apocalypse when Delphi 11 removed that field from TCustomForm.

Hm, I didn't read that comment when I used AssertErrorProc for tracing process flow. Never had any problem with the following procedure assigned to it: var gblAssertTraceOn: Boolean = False; var Trace: TStringList = nil; procedure DebugAssertLine(const _Message, _Filename: string; _LineNumber: Integer; _ErrorAddr: Pointer); var Line: string; begin if gblAssertTraceOn then begin if not Assigned(Trace) then Trace := TStringList.Create; Line := ChangeFileExt(ExtractFileName(_Filename), '') + ':' + IntToStr(_LineNumber) + ' ' + _Message; Trace.Add(Line); end; end; But on the other hand, these calls were no error conditions but simply Assert(False, 'Some descriptive text'); In the end the content of the Trace list was written to a file. It allowed me to write a trace log with information like filename and line number which is difficult to get otherwise. No idea whether using a local variable and the temporary storage used for string concatenation and all these function calls can actually become a problem. Also the code in question is single threaded. I'd never use this in production code though.