dummzeuch

I'm currently on vacation with intermittent internet access and only a notebook computer. I'll try to have a look later today, but I can't promise anything.

So far, any Delphi library or tool that Embarcadero bought has been abandoned sooner or later. What makes you think this would change?

Sorry, I missed that bit.

There is always the option of generating simple text files and synchronising them to other computers. But I guess that's not what you are after.

Res is a Boolean variable.

See my first answer above. It contains the code you need, just replace (x, y-i) with HasPixelAt(x, y-i). https://en.delphipraxis.net/topic/8900-for-i-x-to-y-inclusive-how/?do=findComment&comment=74894

It takes a snapshot of the metadata of the files (name, size, properties ...), not the files themselves. That's how that function works, as far as I know. Whether you think it makes sense or not, doesn't affect that.

FindFirstFile creates a snapshot of the files that exist at the time it is called and returns a handle to that list. FindNextFile then only enumerates over that already existing list. (You also need to call FindClose afterwards to free the internally used resources.) If during that time a file is created or deleted, the list remains unchanged. You will have to check for this in your code. As fpiette said: You might want to use FindFirstChangeNotificaton etc. instead. But even then you will have to check whether the files still exist.

So, what is (x, y-0) etc. meant to evaluate to? That's not a Boolean expression nor an integer that could be processed with a bit manipulation. Ok, assuming this somehow is a Boolean anyway, that's the code I'd use: Res := True; For i := 0 to 7 do begin If not (x, y-i) then begin Res := False; Break; End; End; if Res then ....

You only need an end for each begin in your code, and a final end at the end of a program or unit. My guess is that your if then else did not use a begin end block.

What I meant is: If the IDE package for the welcome page is removed from the list in the registry - which is the way I usually use to get rid of it - the WelcomePagePluginService will forever stay nil.

Creating forms that will never be shown nonetheless take time an resources to create, it also opens the door for unintended side effects. That's why I don't like the way the expert (and now also the welcome page plugin) handle the creation of the form. I'm not sure. I just played a bit with it and it is actually quite nice to be able to move files between folders using drag and drop without having to open the Favorite Files window. On the other hand, it prevents a lot of possible problems if the welcome page plugin is read only. So, let's do it the easy way: Read only it is. (I also just found that there are several bugs in that form: * The property menu item is never enabled. * F2 always edits the file, even if the tree view is active control. * The popup menu for the files works only if the view is not "Details" or no file is selected These are really odd.)

Someting else just occurred to me: What, if the welcome page plugin is not available? Some people might not want that page and remove the plugin. So I tried that and it turned out that WelcomePagePluginService will always be nil and the timer will run until the IDE exits. Which means that there should probably a counter or something similar that limits the number of calls to the timer event before giving up.

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.