dummzeuch

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.

I have installed it on 8.1 too (and another installation on Windows 10). But since 4.1 isn't stable enough for me to use it in every day work, I can't really say whether there are any Win 8.1 specific issues.

The version.res file is generated by the prebuild script (when it works).

The space character in the path might cause this.

The regex you posted here got mixed up by the editor/browser. There is no way we can help you based on that code. Do as @FredS suggests: Use a tool to try this regex.

You don't need to run any batch file, but you must be sure to check out the sources including the externals, in this case dzlib and buildtools. The pre- and post-build scripts need buildtools. Oh, yes, I forgot to implement that button. I never use it and prefer drag and drop or autocomplete. I just added it out of habit. (Hm, why is this text larger now? Sometimes the mobile interface does strange things.)

I think the problem with the Menu Shortcuts expert is, that it only changes the shortcut for the menu item, not that for the associated action. I guess I'll have to look into this a bit further. @Carlos Tré It's odd that changing the action's shortcut does not change the shortcut of the popup menu entry. They both use an action with the same name. Maybe these are two different actions? Not impossible given the mess some of the IDE modules present.

The ToolsApi unit declares the IOTAProcess interface as follows: IOTAProcess = interface(IOTAProcess150) ['{FBECB2A2-80BF-400D-B4A6-0BCEABC2FF7D}'] { Read the process memory at the given address } function ReadProcessMemory(Address: TOTAAddress; Count: Integer; var Buffer): Integer; overload; { Write to the process memory at the given address } function WriteProcessMemory(Address: TOTAAddress; Count: Integer; var Buffer): Integer; overload; Unfortunately it does not say what the function results mean, and I haven't seen any code that checks that result. My assumption from the values I have seen is that these functions return the number of bytes read / written, but is that true? Is it documented anywhere?

Apparently the new experimental Filter Exception expert does not work when debugging IOS or Android apps (and probably also not for Linux programs). There is a bug report on the Embarcadero Quality Portal on crashes when debugging IOS apps. Uninstalling GExperts or disabling the Filter Exception expert solves that issue. Does anybody have similar experiences with other platforms? I had a look at the code again and figured that the problem might be that it hooks/calls TNativeDebugger methods in win32debugide*.bpl. Maybe it should instead call one of the other *debugide* packages: gdbdebugide (Linux)? ios32debugide ios64debugide But on the other hand I don't really care because I don't do any development for anything but Win32 (and possibly Win64 in the future). So I am thinking about disabling the expert when a project for non windows platforms is active instead. It should definitely not crash the IDE.

The WinApi functions return a BOOL, not a number. They have an additional parameter for that: BOOL ReadProcessMemory( HANDLE hProcess, LPCVOID lpBaseAddress, LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead );

Yes, if they are in the current context. That should be no problem with constants declared in the system unit, but for other constants that might not be the case. Hm, thinking about it: I wonder whether this is still true for parts of the IDE that are not written in Delphi...

You are right. It's there in Delphi 10.4. I was looking in Delphi 10.2, where it isn't^D^D^D^D^Dis also right there in that same menu. But: Even in Delphi 10.4, if I remove the shortcut from the main menu entry with GExperts, it still gets shown in the editor's popup menu. And pressing Ctrl+D still calls the formatter.

I now read those vmt offset values from the debugger using IOTAThread.Evaluate. Works fine for Win32 and Win64. Can't test other targets.

That was my first thought too, but unfortunately there is no main menu entry for it, and GExperts only supports man menu entries to assign keyboard shortcuts.

I need the values for the constants vmtArcOffset and CPP_ABI_ADJUST (declared in the System unit) for various platforms. I know them for Win32 (both 0) Win64 (0 and 24 = 3*SizeOf(Pointer64)) Android32 (0 and 12 = 3*SizeOf(Pointer32)) Android64 (0 and 24 = 3*SizeOf(Pointer64)) IOS64 (0 and 24 = 3*SizeOf(Pointer64)) OSX64 (0 and 24 = 3*SizeOf(Pointer64)) Could somebody who develops for other platforms please look them up and tell me? IOS32 OSX32 Linux I'm not sure about the vmtArcOffset and how it changed for different platforms when Embarcadero introduced and when they later dropped ARC support. the automatic reference counting ARC support supposedly sets vmtArcOffset = 2 * SizeOf(Pointer).

I found an easier solution: I'm now using IOTAThread.Evaluate to get the values of these constants (actually I needed vmtParent and vmtClassName which I originally wanted to calculate like the RTL does). Seems to work and doesn't even require me to know the target platform.