Leaderboard

Hi everyone, Following fast on my last post, I thought I'd also share another development I've started - a Console Manager for the Delphi IDE. This is a tool that allows you to spin up a cmd.exe or powershell.exe within a dockable form, localised within the Delphi IDE. Features: - It is aware of the active project, so it will open up in the directory in which the dproj is located. It is still very alpha as in it just streams stdout/stdin, and not totally pleasant on the eye, but ok for an alpha POC. - I've got a little slider that allows you to zoom in/out. - (planning) The ability to have lists of commands / saved environments that could be applied to a newly created session. This is a POC, and still have some more work to do as I want to embrace the new pseudo console api which was introduced with the new Windows Terminal drive along with the VT emulation which would support colour, repositioning of the cursor, etc. I have not released this publicly yet, but attached is a short video demonstrating how it works. If you are interested in accessing it, please send me a mail: conrad.vermeulen@gmail.com. Let me know about what IDEs versions you may be interested in. I think I can do XE8 onwards. I'll provide more information when it is officially released. Regards, Conrad

If a user has modified the behaviour or installed an app that causes the "open" verb to behave differently than the default behaviour - that is a user problem, IMO. If you want to open a .pdf file, "open" is the way to go.

It's not pointless. It's really important to know how the system works. These details matter. Details are important when programming. Makes no sense to recommend the 99.99% correct option over the 100% correct option. Obviously it's not likely to go wrong, but once you know how the system works why on earth would anybody opt to make an intentional mistake?

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

Not necessarily. For instance if your dpr file references them in the other order then it won't be that way. And other unit use clauses can confound you. Enforcing dependencies in initialisation order is not robust. I prefer to find a different way to solve such problems.

Isn't this just the age old issue that Delphi's RTL unmasks floating point hardware exceptions, but most other tools (including the MS tools) mask them. So the ActiveX control that implements the embedded browser expects floating point hardware exceptions to be masked and is caught out by your host having unmasked them. Resolve the problem in the traditional way by masking floating point hardware exceptions. There are countless SO posts on this subject which will show you how to do this.