Dolphin exe with parameters and no GUI

Hello:

I haven't the Prof. version to try, and want to know if it is possible to
develop an exe that can be called with some paremeters, by example:

program.exe /textmail /recipient

Then the program must start, read the parameters and make something (in this
case send a mail reading the text from some file to a recipient).

The same program must have a GUI to make the same, but when is called with
parameres, then don't have to show the GUI.

That's is possible?.

Thanks in Advance.

Germán.

Germán,

> I haven't the Prof. version to try, and want to know if it is possible to
> develop an exe that can be called with some paremeters, by example:
[]
> That's is possible?.

Yes, the Windows command line is available (using the normal argc and argv
names) so you can parse it for arguments, although there may be some
restrictions on what you can include. For example, I'm not sure how it
behaves now if you include spaces within quotes - it *used* to ignore the
quotes and give each part as a separate argument.

Whether or not you open a visible Shell is also up to you.  If your
RuntimeSessionManager subclass (that is where all this is usually done) just
performs some task and quits then there will be nothing displayed on the
screen.  However, there may also be some extra steps needed if you want to
do certain things but don't have a visible Shell - I think the main message
loop might have to be warned to prevent it thinking an error has occurred?

Ian

"Germán S. Arduino" <[hidden email]> wrote in message
news:aoml2d$nevjg$[hidden email]...
> Hello:
>
> I haven't the Prof. version to try, and want to know if it is possible to
> develop an exe that can be called with some paremeters, by example:
>
> program.exe /textmail /recipient
>
> Then the program must start, read the parameters and make something (in
this
> case send a mail reading the text from some file to a recipient).
>
> The same program must have a GUI to make the same, but when is called with
> parameres, then don't have to show the GUI.
>
> That's is possible?.

Yes, it possible, although you will have to trick Windows a bit to make it
work.

Some background: On Windows console and GUI applications are distinct
things. The executable header indicates that the .exe is a console or GUI
app - the "subsystem" is either "Windows CUI" or "Windows GUI" for Console
UI and Graphical UI respectively. Console I/O (stdin/stdout/stderr) is
possible from a GUI app, even the Dolphin IDE. This can be useful when
testing. Try for example:

    SessionManager current stdout nextPutAll: 'Testing, testing'; cr; flush.

However this output must always be to a "new" console window allocated by
the app., not to the console/command line from which the app was started. I
presume this is because when a GUI app. is started from the command line,
control returns immediately (try it by typing notepad.exe in a command
prompt), whereas a proper console app takes ownership of the console, and
the command prompt does not reappear until the console app finishes.

However, it seems to be perfectly OK to open windows, etc, in a CUI app, so
fundamentally what you need is a console app that has a GUI, rather than the
other way around, at least from the point of view of Windows. In order to
deploy such a hybrid from Dolphin though, it is easiest to start by creating
a GUI app, and then imbue it with some of the attributes of a console app.
This is done by first defining a RuntimeSessionManager subclass (as normal).
The #main method decides whether or not to open a window based on the
parameters, accessible as #argv. You then need to copy  certain methods from
ConsoleSessionManager so that console I/O does not cause a new console to be
allocated, and so that the console executable "stub" is used as the basis
for the application deployed by Lagoon. Note that you can't use "ToGo" mode
(single-file .exe, no separate VM), because the ConsoleToGo stub omits
certain GUI related facilities in order to keep its size down to a minimum,
so you must ship the VM with the executable, although it would be possible
to create an appropriate ToGo stub.

I've attached a simple sample package that does all this. I had to remove
the image stripper set up, because I think it would get corrupted when
included as part of a plain text attachment. In order to deploy the app just
choose a name for the executable file at Step 2, and uncheck the "ToGo"
option. Otherwise accept all the defaults, and press Deploy.

Regards

Blair

------------------------------

| package |
package := Package name: 'Hybrid'.
package paxVersion: 0;
 basicComment: ''.

package classNames
 add: #HybridTestSessionManager;
 yourself.

package binaryGlobalNames: (Set new
 yourself).

package globalAliases: (Set new
 yourself).

package allResourceNames: (Set new
 yourself).

package setPrerequisites: (IdentitySet new
 add: '..\Dolphin\Base\Dolphin';
 add: '..\Dolphin\MVP\Base\Dolphin MVP Base';
 add: 'MVP\Hello World\Hello World';
 yourself).

package!

"Class Definitions"!

RuntimeSessionManager subclass: #HybridTestSessionManager
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 classInstanceVariableNames: ''!

"Global Aliases"!


"Loose Methods"!

"End of package definition"!

"Source Globals"!

"Classes"!

HybridTestSessionManager guid: (GUID fromString:
'{A9F65DA9-F658-4660-92DC-1854BA062D76}')!
HybridTestSessionManager comment: ''!
!HybridTestSessionManager categoriesForClass!System-Support! !
!HybridTestSessionManager methodsFor!

allocConsole
 "Private - Open a console window for this session."

 !

main
 "If the user passed any parameters, echo them back onto stdout and finish.
If not then open a window."

 self argv size > 1
  ifTrue:
   [self argv from: 2
    keysAndValuesDo:
     [:i :each |
     (self stdout)
      cr;
      print: i;
      nextPutAll: ': ';
      nextPutAll: each;
      flush]]
  ifFalse: [HelloWorld show]!

openConsoleStreams
 "Private - Open the standard console I/O streams.
 In this case we attach to pre-existing C run-time library stdio streams, as
they
 will be correctly set up."

 stdioStreams isNil ifTrue: [ | crt |
  crt := CRTLibrary default.
  stdioStreams := Array new: 3.
  0 to: 2 do: [:i | stdioStreams at: i+1 put: (StdioFileStream fromHandle:
(crt getStdHandle: i))]].

 "Note that all the above streams should be in text/translating mode"! !
!HybridTestSessionManager categoriesFor: #allocConsole!operations!private! !
!HybridTestSessionManager categoriesFor: #main!operations!public! !
!HybridTestSessionManager categoriesFor:
#openConsoleStreams!operations!public! !

!HybridTestSessionManager class methodsFor!

isConsoleApplication
 "Answer whether the sessions managed by instances of the receiver are for a
console application
 (as opposed to a GUI application, which is a completely separate thing
under Windows).
 Implementation Note: This isn't really a console application, but the test
is slightly misnamed
 since it really means is this not a GUI application."

 ^true!

mainShellClass
 "Answer the class of the application's main window (a <Shell> presenter)."

 ^HelloWorld! !
!HybridTestSessionManager class categoriesFor:
#isConsoleApplication!public!testing! !
!HybridTestSessionManager class categoriesFor:
#mainShellClass!constants!public! !

"Binary Globals"!

"Resources"!

"Ian Bartholomew" <[hidden email]> wrote in message
news:EXBr9.3460$Lm1.276835@stones...
> Germán,
>
> > I haven't the Prof. version to try, and want to know if it is possible
to
> > develop an exe that can be called with some paremeters, by example:
> []
> > That's is possible?.
>
> Yes, the Windows command line is available (using the normal argc and argv
> names) so you can parse it for arguments, although there may be some
> restrictions on what you can include. For example, I'm not sure how it
> behaves now if you include spaces within quotes - it *used* to ignore the
> quotes and give each part as a separate argument.

Just to clear up any confusion, this is no longer relevant. Quoted arguments
containing whitespace will appear as single entries in the argv array, with
the quotes stripped off.

Regards

Blair

Thanks by your response Blair.

I will make some tests.

Thanks by your time.

Regards.

"Blair McGlashan" <[hidden email]> escribió en el mensaje
news:aooid9$oivie$[hidden email]...
> "Germán S. Arduino" <[hidden email]> wrote in message
> news:aoml2d$nevjg$[hidden email]...
> > Hello:
> >
> > I haven't the Prof. version to try, and want to know if it is possible
to
> > develop an exe that can be called with some paremeters, by example:
> >
> > program.exe /textmail /recipient
> >
> > Then the program must start, read the parameters and make something (in
> this
> > case send a mail reading the text from some file to a recipient).
> >
> > The same program must have a GUI to make the same, but when is called
with flush.
>
> However this output must always be to a "new" console window allocated by
> the app., not to the console/command line from which the app was started.
I
> presume this is because when a GUI app. is started from the command line,
> control returns immediately (try it by typing notepad.exe in a command
> prompt), whereas a proper console app takes ownership of the console, and
> the command prompt does not reappear until the console app finishes.
>
> However, it seems to be perfectly OK to open windows, etc, in a CUI app,
so
> fundamentally what you need is a console app that has a GUI, rather than
the
> other way around, at least from the point of view of Windows. In order to
> deploy such a hybrid from Dolphin though, it is easiest to start by
creating
> a GUI app, and then imbue it with some of the attributes of a console app.
> This is done by first defining a RuntimeSessionManager subclass (as
normal).
> The #main method decides whether or not to open a window based on the
> parameters, accessible as #argv. You then need to copy  certain methods
from
> ConsoleSessionManager so that console I/O does not cause a new console to
be
> allocated, and so that the console executable "stub" is used as the basis
> for the application deployed by Lagoon. Note that you can't use "ToGo"
mode
> (single-file .exe, no separate VM), because the ConsoleToGo stub omits
> certain GUI related facilities in order to keep its size down to a
minimum,
> so you must ship the VM with the executable, although it would be possible
> to create an appropriate ToGo stub.
>
> I've attached a simple sample package that does all this. I had to remove
> the image stripper set up, because I think it would get corrupted when
> included as part of a plain text attachment. In order to deploy the app
just finish. as !
> !HybridTestSessionManager categoriesFor: #main!operations!public! !
> !HybridTestSessionManager categoriesFor:
> #openConsoleStreams!operations!public! !
>
> !HybridTestSessionManager class methodsFor!
>
> isConsoleApplication
>  "Answer whether the sessions managed by instances of the receiver are for
a
> console application
>  (as opposed to a GUI application, which is a completely separate thing
> under Windows).
>  Implementation Note: This isn't really a console application, but the
test
> is slightly misnamed
>  since it really means is this not a GUI application."
>
>  ^true!
>
> mainShellClass
>  "Answer the class of the application's main window (a <Shell>
presenter)."

> However, there may also be some extra steps needed if you want to
> do certain things but don't have a visible Shell - I think the main
message
> loop might have to be warned to prevent it thinking an error has occurred?
>
> Ian
>

Hello Ian:

It's supposed that the caller program (not a Dolphin program) can read some
interchange file
wroted by the console Dolphin program and display msg errors or so.

Thanks by your time and help.

Regards.

Germán.

Blair,

> Yes, it possible, although you will have to trick Windows a bit to make it
> work.

That's got me slightly worried now :-)

I've got a backup application created using Dolphin that can be started in
two ways
- no command line argument. The main shell is displayed and allows access to
a model that can perform backups etc.
- any command line argument.  No shell is opened but a new instance of the
model is created and an auto backup performed (scheduled task at 04:00)

It all seems to work.  Are you saying I should create a console for the
"unattended" mode or else strange things might happen?.

I've a horrible feeling I'm missing the point of your, or Germán's, post
though...

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:sJRr9.9$OC2.676@wards...
> Blair,
>
> > Yes, it possible, although you will have to trick Windows a bit to make
it
> > work.
>
> That's got me slightly worried now :-)
>
> I've got a backup application created using Dolphin that can be started in
> two ways
> - no command line argument. The main shell is displayed and allows access
to
> a model that can perform backups etc.
> - any command line argument.  No shell is opened but a new instance of the
> model is created and an auto backup performed (scheduled task at 04:00)
>
> It all seems to work.  Are you saying I should create a console for the
> "unattended" mode or else strange things might happen?.

No, I don't think so. I assumed that Germán wanted an app that would behave
like a true console app when not displaying a GUI, in which case it ought to
do I/O to the command prompt window that started it, like a normal command
line app would. If this is not required, then there is no problem about
creating a standard GUI app. The only difference would be that if you do any
console I/O from the GUI app, it will go to a newly allocated console rather
than the command prompt used to start the app. Also the command console will
return to the prompt immediately, rather than waiting for the app to
terminate. Finally if you double click on a console app., Windows will open
a console automatically, whereas a GUI app must do this explicitly, although
this isn't much of a concern in Dolphin since the session manager will open
one automatically as soon as one attempts to access any of the stdio
streams. As far as I've been able to determine, these are the only real
differences between a Win32 CUI app and a Win32 GUI app.

In the case of an unattended application like your headless backup, I would
have thought the way you currently have it is correct. Any error messages,
etc, should probably be direct to the event log in that case, and normally
one would assume that user input is not available.

Regards

Blair

Another option, if the point is simply to make a GUI app run synchronously
from a command line (or from within a  .bat or .cmd file), is to use the
start command with the "/wait" argument.  In the case of notepad.exe, then:

start /wait notepad.exe

will start notepad.exe, but control doesn't return to the command processor
that invoked it until notepad exits.

I don't know whether it's available on Win9X, but it's included in WinNT
systems at least since 4.0.

Don

Blair,

> In the case of an unattended application like your headless backup, I
would
> have thought the way you currently have it is correct. Any error messages,
> etc, should probably be direct to the event log in that case, and normally
> one would assume that user input is not available.

Thanks for the confirmation (and the earlier update on embedded spaces in
command line arguments).  I guessed this might be the situation, especially
as it has worked in one form or another for a couple of years now without
any major hitches, but it's nice to have it confirmed.

Ian