dummzeuch

No, but I noticed that the problem hasn't been fixed in 10.4. Never looked at it in 10.4.1 because I found a different way that does not require a dotNET assembly. That was my "last best" solution anyway. (* "second best" would put it too mildly. Avoiding this was by far the best option.)

Hm, when will Microsoft start to rewrite Office to use WinUI? Until that happens, I am skeptical whether this will be worth the effort. But I am only a disgruntled old white man^d^d^d^d^d^d^d^d^dVCL developer.

I wrote the Convert Strings expert several months after somebody else donated the String Paste expert, because I could never remember how to use the latter. I always wanted to clean up this mess, but never came around doing it.

Have you looked at the newer "Convert Strings" expert? There is a favorite called "SQL-to-String" which seems to do exactly what you want

OK, even though you didn't file a feature request, I just implemented this in revision #3370.

Would you please file a feature request on SourceForge for this? That is the central point where I look when I have some time and feel like implementing some small improvement. Also, others might see this, implement it and send me a patch (yes, this has happened). Of course you could also do that yourself.

If the order is important, it's not the order of installation but the order loading the plugins. So disabling all of them and then enabling them in the desired order should do the trick.

somebody named "Gilles The cat" just posted this in the Delhi Wiki: https://delphi.fandom.com/wiki/Forum:Old_component Maybe somebody here can help.

Apparently he had already asked DevExpress and they cannot supply the old version. (He could have mentioned that rather than let us (me) guessing. I didn't know what tdxfOutlootBar is/was and from they way he formulated his questionI thought he didn't either. That's what you get for trying to help. I should have known better. 😞 )

The first Google hit for you might have been that. I didn't see this on the first page of results. The joys of personalized search...

Ah, this was about Delphi, not GExperts.

Where?

So, to sum it up: The "dx" in the name is a strong hint that it is from DevExpress, so it should be possible to get this component from them, even for Delphi 5. Correct?

Fixed that in revision #3369 Thanks for the hint.

I just added the following feature request: https://sourceforge.net/p/gexperts/feature-requests/127/ That would solve your problem.

Partly wrong: From Delphi 2007 to Delphi 2010 there were 4 entries: DCC_IncludePath DCC_ObjPath DCC_ResourcePath DCC_UnitSearchPath which the IDE all filled with the content of the Search path from the Project Options dialog Starting from XE there is only the entry DCC_UnitSearchPath.

I just found that it is possible to set the search path via OTAPI IOTAProject.GetProjectOptions.Values['DCC_UnitSearchPath'] So in theory it's possible to create a plugin that searches for dcu / pas files, creates a list of possible directories and allows the user to add directories to the search path. Not sure about the amount of work that is necessary for this. It needs a UI too.

done: https://osdn.net/projects/directorycollector/

"a program that simply collects paths dropped on it"

On second thought: This doesn't really solve your problem. You still have to add these dirs to the search path, compile, find the next one which is missing, add it and start again. Btw: GExperts makes the search path dialog accept dropped directories already.

Took me less than 10 minutes. Here you go. I'll put the source on OSDN later. DirectoryCollector.zip

Unfortunately adding to the unit search path of a dproj file is a mess since there are at least 4 entries that need to be changed (maybe one could get away with changing only one and leave it to the IDE to add to the others, but I don't know which one that would be). But creating a program that simply collects paths dropped on it, is far from rocket science. I think I'll put one together within the next 30 minutes.

Tired of all those programs which install lots of additional stuff I have been using more and more so called “Portable Apps”. “Portable” in this context means: You can put them anywhere, even on a portable storage device and start them from there. These Programs are still Windows only. And of course nobody prevents you from putting them in a folder on the system harddisk, usually c:\PortableApps. All files these programs need are inside this one folder, so in order to move or copy them, you simply move/copy that folder. There is a dedicated launcher and updater for these types of programs at portableapps.com, which is written in Delphi btw. and the source code is available. One thing that has irked me all the time is that these programs don’t show up in the Windows start menu, unless I add them manually, which I usually don’t. Today I had enough and wrote PortableAppsToStartMenu, a tool which given a PortableApps directory collects all the executables stored there and creates shortcuts in the Windows Start Menu for them. Read on in the blog post.

@limelect I just fixed a few problems in the build scripts regarding directories and file names containing space characters. It works for me now. Try again, but remember to check out the trunk, because that's where I made these changes.

Did you try a path without space characters? Simply move the project directory to e.g. g:\sources and try the build script again.