dummzeuch

Many open source projects have moved from the former top dog Slashdot to GitHub and in the process usually converted from Subversion to git. This also includes quite a few Delphi libraries like project Jedi (JCL/JVCL), SynEdit or Indy. I am not really comfortable with git, it just feels too complex for most projects and the GUI tools I have tried are clunky compared to TortoiseSVN. I see some advantages, but so far I’m not convinced. So, I have stayed with SVN and used that to access GitHub repositories through their git-svn bridge. This works fine, most of the time, unless you want to rename a file, which apparently is not possible for whatever reason. Now, contributing to such projects is another challenge. You need to create something called “pull requests“, which basically is a way of creating patches that are centrally managed by GitHub together with a discussion area for them. It took me a while to get my head around the process but I think I got it now. Read on in my blog post.

Ok, here it comes: Let me first state that I like that code in general. What I am saying after this is mostly nitpicking. 1. I don't like it that TFavoriteFilesExpert.RegisterWelcomePage is used as the OnTimer event handler as well as directly called from TFavoriteFilesExpert.AfterIDEInitialized. These should be two different methods and maybe a third that does the actual registration. Each of these methods would be much easier to understand than this one method. 2. I wasn't aware that there are 3 copies of the code that creates the TfmFavFiles form. You have now added a 4th one and then changed the parent of the treeview and listview on it. If you add some comments like this, I'm fine with that, even though it feels more than a bit hacky. // we create a new instance of the form here and then change the parents of the treeview and listview to our welcome page frame. // The form will continue to handle all events but will not be visible. (This is how I understood that code. If I'm wrong, please correct the comment.) A proper solution would be to move these controls and the associated event handlers to a frame and only instantiate and use that frame. 3. Where does the source preview on the welcome page come from? Even if that gets created by the form, it does not get it's parent changed so it should not be visible on the frame. I don't think it makes much sense there either. 4. I'm wondering whether this could create a problem: procedure TGXWelcomePagePlugin.DestroyView; begin FreeAndNil(FFavFiles); FreeAndNil(FView); end; The tree and list view are now part of the form (via the owner relationship) and also part of the frame (via the parent relationship). Both will try to free them. Since the form will be first the internal notification logic between a control and its parent might prevent the control from being freed twice. 5. If there is only one node in the tree view, that tree view does not make sense in the welcome page and should not be shown at all. 6. On the other hand, the tree view still has its popup menu, so it would be possible to add and remove nodes from it. (why doesn't the list view have it?) But what happens, if the user changes the configuration while the welcome page plugin exists and has its own copy of the form? I think those changes will get lost becaise the get overwritten by the form instance created by the welcome page plugin. But I am not sure, I haven't traced that code yet. 7. You will also have to put an ifdef around the finalization code.

I had some bad experience with the hosted SVN repositories of my open source projects (first with SourceForge, now with OSDN) so I decided to sync all of them to a local, read only copy on my hard drive. In the worst case that will keep the history even if the hosting service goes down permanently and loses the data. The command for that, according to the book is svnsync. The local repository must be prepared first, though and that turned out a bit more complicated than I expected, so I’m posting this here for future reference. Read on in the blog post.

Why would I need that? I have an svn repository and I'm making a copy of that. No git involved, and none needed.

If you send me (or attach) the full source code of the changed / added units, or a patch, I'll give it a try and start bitching^d^d giving feedback about it in earnest.

That's ok with me. I don't like git or rather think it overly complicated for what I need. And I managed to trash my git repositories several times when I tried to get used to it a few years back. Those projects that move / have moved to GitHub have their reasons. They'll just have to live with the fact that I'll not contribute to them. Most of them probably don't care, my contributions haven't been that great anyway.

Could you please also submit it as a bug report? I'm looking into that category more often than feature requests and if I create it you won't get notification emails on it. I'll delete that feature request after you have copied it. (I don't understand why feature requests and bug reports are two distinct databases rather than just categories in the same one. If that were the case I could simply change the category and be done.)

If I remember correctly, C++ Builder can also compile Delphi units and allows C / C++ code to call Delphi code. The other way round is not possible. I assume that this is still the case? So if I want to call C code, I have to compile that code to an .obj file and link that to the Delphi program, which means that debugging that code requires a C++ Builder project (or some other C compiler + debugger). Correct? (If I don't want to single step through assembler code, that is).

Interestingly even with the DLL from the 2023-03-25 release formatting that unit works fine on my computer. I wonder whether the problem is related to a specific processor type. You won't find that version anywhere because it was never released. Iain is probably using a DLL he compiled himself from the current sources, which are revision #4026 in the svn repository. But of course you could update your sources and do the same.

Formatting that unit works fine for me.

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.