SwiftExpat

Another affordable disk image solution is https://www.oo-software.com/en/diskimage-backup-your-data Sign up for the news letter and you can usually get a copy between $10 - $20 USD.

One item you might try is to use TPath to get the full path of a file in your working directory (the file does not need to exist). That would give you the working directory at that time. program CheckWorkDir; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.IOUtils; begin try writeln('Working Dir = ' +TPath.GetDirectoryName(TPath.GetFullPath('pid.txt'))); except on E: Exception do writeln(E.ClassName, ': ', E.Message); end; end. output: c:\Data>C:\Users\Coder\Documents\Embarcadero\Studio\Projects\OSUtils\TouchFile\Win32\Debug\checkworkdir.exe Working Dir = c:\Data\ c:\Data>cd ibd c:\Data\ibd>C:\Users\Coder\Documents\Embarcadero\Studio\Projects\OSUtils\TouchFile\Win32\Debug\checkworkdir.exe Working Dir = c:\Data\ibd

If you are open to using WMI, check out https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-process You can see an example output running this at a command line: wmic process

I played a little more with this, but honestly it is no less code than what you already wrote, basically a recursive loop writing a JSON. This statement form Uwe helped me understand the complexity better. FNC gets the object type using RTTI, so I am not sure it is worth trying to trick / persuade it. StyleAPI is an example of how to seal an API. Since the reference is via an include, I would be tempted to copy it and modify visibility. Zoe, you deserve a thanks for digging through the API and making an export with it.

David FNC has a "Tool Bar Button" which has some rounded corners. Might be worth a look.

TMS FNC Core has a a library that works with published properties. It is licensed with FNC. TMS blog post describing it here: https://biz.tmssoftware.com/site/blog.asp?post=646 Here is your code forked / converted to work with FNC : https://github.com/SwiftExpat/vsf2json . EXE and a json sample are in the releases so you can try it out if you like. I had to derive a class to include the list of style objects, but not much code to write at all. TExportStyleSource = class(TSeStyleSource) public function GetStyleObjects:TList; published property StyleObjects: TList read GetStyleObjects; end;

This is correct, you can see sample source code on Github here with compiled demos here. The component is a simple button which is appropriate for starting out. In an established application I take the approach to not use any extra space on the form by utilizing an onclick event handler of a label. The FMX sample shows a click 3 times on a label to invoke, similar to the 7 long presses in Android. This design allows you to ifdef out the code for your release and not modify the form. Note the ifdefs in the samples. This is correct. This code maintains the tree of forms, data modules, components. The Inspector loads the component details but is not automatically aware of changes that occur. On the Inspector tab there is a button that always allows you to reload. In general workflow it stays up to date, but depending on what events are assigned on the component you may need to reload. An example would be modifying the align edit1 from center to client, The Inspector updates the align property because it is aware it made the change. The width still shows 100 as in the Inspector because it is unaware of the new width due to alignment. A click on the reload button will force it to load the current values.

At runtime my component "Marshal" creates a form dedicated for inspection. This is where you inspect and have access to the components. My offline application "Caddie" captures your actions in Marshal and lets you review them later. This is organized by application and is not connected to the runtime copy. Together they make up the Runtime Toolkit. The challenge I attempt to solve is documenting modifications at runtime so you can ensure the correct changes are made in your source code. I like Marco's original tool, but I found myself not remembering what I modified to fix my issue. I appreciate your features requirement clarification, but at this point I only do component inspection.

Also worth mentioning from TMS is with the FNC UI pack you get an object inspector. Note in the documentation it calls out that you are inspecting published properties only. TMS FNC Object Inspector does not populate a tree of the application components, it is just the Inspector. https://www.tmssoftware.com/site/tmsfncuipack.asp?s=fncobjectinspector#features To your original question of all classes and objects, it is worth considering visibility and ownership. The component tree is populated based forms / data modules owned by the application, then components owned by the form. Consider if you are creating components at runtime and the owner is assigned to the form, if not then the component will not be visible. I have used it to inspect some of by business objects, with the condition that the property is published. It also has events so that you can make properties read only at runtime. Take a look through the PDF and see if it fits your needs. If you desire a component tree you could build / buy something like my product, I do not include a license to FNC UI pack, it is a separate purchase. Some youtube videos are available at https://swiftexpat.com that will give you an overview.

For me this confirms it is cached. I would not waste time in perfmon. I would go with @Kas Ob. and his number 5. I have never read into any of that material but it sounds like a logical boundary that the OS would not allow you to cross.

Have you used Task Manager to watch the cache counter in the Memory tab? It is a good place to start before perfmon. While that disk might look local to you, it is likely on some storage array which could have some block caching. Consider how much RAM is on that server to cache with and how busy is that server when you are executing your programs. Perfmon with some counters set around physical disk, % idle time, read queue length, reads per second and is a good place to start to see when it is actually hitting the physical disk and if it is waiting on disk. Compare your reads per second against run 1 an run 2. Also grab the cache counters and look to see if any of them spike on a second run, this will give you an OS cache look.

They are not nearly the same functionality, stick with TMS. I think of it like this, PY4D loads python39.dll into Delphi at the api level. At this point you have an execution engine. As a developer you want / need to wrap your Delphi API to make it python friendly / usable. A justification would be to python enable your end users as some sort of marketing selling point. I fear you would be teaching / debugging your end user python which is copy paste from the internet. It is valid large investment if you want to grow out of your application something like this where the Wing IDE is interacting with Blender. Look at this as an example and just imagine the work to get there. https://wingware.com/doc/howtos/blender

I do not have a solution for this, but have some thoughts to explore this further: Do you really need the IDE embedded in your application or could you treat it as a remote execution / debug scenario? Which code, Delphi or the Python script, do you need the user to be able to watch / step into? --how deep does the customer really need to watch into your Delphi code, first public level only? Could you use PY4D to host the interpreter and then remote attach to it with the IDE? --this is probably the path to aim for, it may require more wrapping of your Delphi code, but then you have options on the IDE side.

Another way to solve the problem, when you need to add / modify to path, order is likely important. Just run the command in python: import sys sys.path.insert(0, 'path/to/script') The engine has a property, PythonEngine.InitScript: PythonEngine.InitScript.Add('import sys'); PythonEngine.InitScript.Add('sys.path.insert(0, 'path/to/script')'); The benefit is when you attempt to run / unit test in python and need to modify the path. And if you use PyScripter as your python dev tool the approach will be reusable.

Christian, It sounds a lot like desktop heap limitation, most likely on the terminal server. A summary document to describe the problem is here: https://techcommunity.microsoft.com/t5/ask-the-performance-team/sessions-desktops-and-windows-stations/ba-p/372473 The registry reference is here: https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/desktop-heap-limitation-out-of-memory the fix is in step 4: In the Value data section of the Edit String dialog box, locate the SharedSection entry, and then increase the second value and the third value for this entry. You can bump those values up 512 at a time and see if it helps. Unfortunately it is a reboot each time. For a more scientific approach, I found this from an MVP. https://thundaxsoftware.blogspot.com/2011/10/monitoring-desktop-heap-memory-and.html