topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday April 25, 2024, 2:27 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - myarmor [ switch to compact view ]

Pages: prev1 2 3 [4]
76
Drag&Drop Robot / Re: Suggestion: Use Comspec
« on: June 06, 2008, 05:43 PM »
But just to clarify i'm understanding things.. if you manually change your commandline item to start with "c:\program files\jpsoft\tcmd9\tcc.exe" then does it do what you want?  OR are you saying that this issue only comes up when D+DR is auto-creating .bat files and launching them (which happens when D+DR sees a commandline that doesnt start with a .exe).

The above seems like a too complicated way to do things..
Yes, cmd.exe is ran when creating temporary batch files too..

This is what happens when running a .bat file:
-- Log from Outpost Firewall --
23:48:20   Command line: cmd /c "D:\tmp\test.bat"
23:48:20   Process CMD.EXE started by draganddroprobot.exe
-----------------------------

The "cmd" part of the line above is what I'd like to have changed with the content of the comspec environment variable.
The issue is caused by anything starting "cmd" instead of the designated command processor.

The point is, instead of executing cmd /c "D:\tmp\test.bat" in the example above you would execute "%comspec%" /c "D:\tmp\test.bat".
Comspec in the preceding sentence is still the expanded contents of that variable.

- Take command understands batchfiles perfectly, but cmd doesn't understand the tcc extensions to the language.
  you can detect inside a batchfile if it runs under the normal command processor or tcc.
- Using the .btm extension would be option, but would result in D+DR first executing cmd, then tcc, for every single file.
- Starting all commandlines with c:\program files\jpsoft\tcmd9\tcc.exe /c might also work, but makes it less flexible
to change (such as tcc changing path, or the configuration and batchfile is delivered to someone without Take command) than just
the straight forward d:\tmp\test.bat .

Another way to support this, if you want to do it the hard way, is to support this type of command typed into the D+DR commandline:
%VARIABLENAME% parameters or, taken a bit longer
%SYSTEMROOT%\notepad.exe "%HOMEDRIVE%\%HOMEPATH%\test.txt"

It might even be more powerful.
D+DR would then simply expand the variable(s) provided before interpreting it, then execute.

This way it would still remain flexible, in which you can write %COMSPEC% /c d:\tmp\test.bat, essensially doing the same as I wish for.

But this was just a small suggestion..


@f0dder, Most likely a CreateProcess or ShellExecute of cmd.exe


77
Drag&Drop Robot / Re: Suggestion: Use Comspec
« on: June 06, 2008, 02:35 PM »
This never occurred to me.
Actually D+DR just tells the OS to launch the program, so the OS takes care of it, but perhaps i could have an option to manually specify a replacement command processor.

If you specify the command processor exe on the D+DR commandline before the program to execute, does it work?

Or do you have any alternative explanation for how to launch another exe programmatically using an alternative command processor.  Remember that D+DR needs to capture the output of the processor in some cases which involves remapping the i/o, so i'm curious to know if this will still work ok.
Yes, D+DR grabs the output as it should when specified on the D+DR commandline.

I'm talking about every time you would normally explicitly call the command processor (as you or a library apparently do with .bat for instance),
not .exe etc extensions.

I have .cmd,.bat and .btm extensions assigned to run with "c:\program files\jpsoft\tcmd9\tcc.exe".
The comspec variable is also assigned that path, so no matter what, everything running a batchfile one way or another
would run with TCC instead of XP's command processor.

I did some testing by creating a small batch file (test.bat) containing only VER
then dropped a file in D&DR, and ran it. It shows XP's command processor:

Microsoft Windows XP [Version 5.1.2600]

with TCC it would've shown:
TCC  9,02.151   Windows XP [Version 5,1,2600]

which it doesn't, ergo D&DR seems to call it directly, ignoring extensions and comspec.

Regarding captures etc.. You should be able to do exactly the same as you already do.

Below I use %comspec% when referring to where you'd use the returned string from SysUtils.GetEnvironmentVariable('ComSpec').

"%comspec%" /c c:\tmp\test.bat
will with the default paths perform exactly the same as
"c:\windows\system32\cmd.exe" /c c:\tmp\test.bat

and (comspec expanded) "c:\program files\jpsoft\tcmd9\tcc.exe" /c c:\tmp\test.bat
would do the same, but with a expanded batch language etc.

Make note of the quotes..
The comspec variable is not likely to contain quotes, but may contain spaces.

78
Drag&Drop Robot / Suggestion: Use Comspec
« on: June 06, 2008, 11:33 AM »
Just a small suggestion for an otherwise excellent program..

Instead of statically calling cmd wherever it is needed, please use the ComSpec environment variable to determine what command processor to use (It's been around since ms-dos, and still exists).
The comspec variable always points to the full path of the command processor to use and doesn't contain parameters.

It wouldn't change anything for standard users, but it would for those that want to use an alternate command processor by default.

In my case I prefer to use Take command by jpsoft which is compatible with the normal command processor, but oh so powerful in comparison.

79
Developer's Corner / Re: SkyIDE - Latest Release Information
« on: May 10, 2008, 08:09 AM »
myarmor, I just saw your reply. Thank you for taking your time to register and post this knowledgeable and very appreciative reply!
No problem.  :)

80
Developer's Corner / Re: SkyIDE - Latest Release Information
« on: May 06, 2008, 07:36 PM »
I was continuing development with BCB 6 instead of 2006 -- as a version of TScintilla was not available at the time for BCB 2006. I don't know about now.

So what is the future? I want to re-write the whole thing with BCB 2006. If a version of TScintilla is available for this version of BCB I will go with it otherwise, I will have to look for somethning else even a commercial tool.

I haven't seen a newer version of Delphisci, but there are instructions at Delphisci Project Page on how to cure the
IDE crashes with it in BDS/Delphi etc 2005+.

If C++ Builder 2006 works in the same manner RAD Studio 2007 does, then you use the exact same compile both for
Delphi and BCB (just make it generate all types of files, not just DCU), then move .bpi/lib files to a directory in the
search/library path to get the components to show in C++ Builder too.

The reason Delphisci 0.23 crashes when clicking on the TScintilla component in the IDE was that versions 2005+ passes a
HDC in wParam to the Scintilla control's WM_PAINT when clicked etc.
Scintilla expects a paintstruct if wParam is nonnull for some reason, something which obviously creates a access violation when given a hdc.

Pages: prev1 2 3 [4]