Queries on distribution of Smalltalk programs

I have two unrelated queries on the distribution of the Smalltalk
application I am working on. I would be grateful if anyone could give me any
pointers on them.

a. I am using Bob Jarvis's External Process mechanism to run a batch program
in the background (and it is very successful). I capture the console output
in a file called conout.txt, and I want to display this to the user only if
it contains any warning or error messages. It is easiest to draw attention
to it if it appears in  a separate window, and I thought a TextDocument
would be the obvious vehicle. I tried:
TextDocument filename: 'conout.txt'
which generates a window with the right heading but nothing in it. Seeing
that TextDocument has a subclass Notepad, I tried:
Notepad filename: 'conout.txt'
and got exactly what I wanted. I am puzzled by this, and as usual would like
to understand what is wrong, but as time is pressing I am happy to stick
with Notepad. However, I am not clear whether Notepad is available for
distribution under the OA licence. It is not part of the development system,
so it should be OK, but I would like to know for sure.

b. I hope to hand out copies of the prototype application for people to
experiment with. It is still only partly working, and needs a lot more
facilities to achieve what I propose, but I suppose there is a chance that
some people might think it worth keeping and using. So I would like to put
in a mechanism which limits the time it will work for. Is there any simple
way of doing this? I am not looking for anything highly sophisticated which
would defeat determined hackers, because I don't think the program will be
seen as that valuable; just something that will encourage users to come back
to me to get the developed system.

Thanks for any help.

Peter Kenny.

Peter,

> a. I am using Bob Jarvis's External Process mechanism to run a batch
> program in the background (and it is very successful). I capture the
> console output in a file called conout.txt, and I want to display
> this to the user only if it contains any warning or error messages.

You just want to display the log, not let the user edit it, so I don't think
Notepad is really needed.  I think you would get much more control if you
get the text from the file yourself and then display it, something like...

(File exists: 'conout.txt')
    ifTrue: [
        fileStream := FileStream read: 'conout.txt'.
        [text := fileStream contents] ensure: [fileStream close].
        text containsErrorsOrWarnings
            ifTrue: [
                m := MultilineTextEdit show.
                m topShell
                    extent: 400@500;
                   caption: 'Error Log'.
                m
                    setReadOnly: true;
                    canVScroll: true;
                    canHScroll: true;
                    text: text]]

or, if the error text is limited in size, the much simpler

(File exists: 'conout.txt')
    ifTrue: [
        fileStream := FileStream read: 'conout.txt'.
        [text := fileStream contents] ensure: [fileStream close].
        text containsErrorsOrWarnings
            ifTrue: [MessageBox notify: text]]

> b.
[]
> for. Is there any simple way of doing this? I am not looking for
> anything highly sophisticated which would defeat determined hackers,
> because I don't think the program will be seen as that valuable; just
> something that will encourage users to come back to me to get the
> developed system.

Maybe a splash screen that is displayed when the app starts and doesn't
allow the app to be used until it disappears.  If you then increase the time
that takes, maybe making it dependent on how long since the app was
deployed, it might be enough encouragement.  If you don't want that then
just check the date when the app starts and, again if too much time has
expired, shut the app straight down.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message news:<[hidden email]>...
> Peter,

> You just want to display the log, not let the user edit it, so I don't think
> Notepad is really needed.  I think you would get much more control if you
> get the text from the file yourself and then display it, something like...
>
> (File exists: 'conout.txt')
Ian

Thanks. I have used your first approach, making it a separate method
which I will use again in similar situations. It is just what I was
trying to do with a TextDocument.

>
> Maybe a splash screen that is displayed when the app starts and doesn't
> allow the app to be used until it disappears.  If you then increase the time
> that takes, maybe making it dependent on how long since the app was
> deployed, it might be enough encouragement.  If you don't want that then
> just check the date when the app starts and, again if too much time has
> expired, shut the app straight down.

The second thing is what I want to do. At the moment I don't quite
know where in the system to insert this test (I use the ToGo exe
approach, and the organisation of the start up is a mystery to me).

Many thanks

Peter

Peter,

> Thanks. I have used your first approach, making it a separate method
> which I will use again in similar situations. It is just what I was
> trying to do with a TextDocument.

You might want to think about wrapping the error display handling in a
Dialog subclass whose view displayed the text, had an OK button and, maybe,
a Help button that could give information about the errors and warnings
encountered.  Probably overkill at this point though :-)

> The second thing is what I want to do. At the moment I don't quite
> know where in the system to insert this test (I use the ToGo exe
> approach, and the organisation of the start up is a mystery to me).

If you are using what the Dolphin education centre calls a "packaged
class-based" technique (you have added a RuntimeSessionManager subclass with
a #main method) then the #main method would be the place, something like....

MyRuntimeSessionManager>>main
    | expiryDate |
    expiryDate := Date newDay: 30 monthIndex: 9 year: 2004.
    Date today < expiryDate
        ifTrue: [MyApplicationShell show]

The application should  (nb I haven't _actually_ tested this code) then only
start if the current date is before your chosen expiry date.

If you aren't using this deployment method then ask again.  This is the only
deployment method I use but I imagine something similar would be possible in
the other schemes using one of the image triggers - #sessionStarted maybe?.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:410a951c$0$2196$[hidden email]...

> You might want to think about wrapping the error display handling in a
> Dialog subclass whose view displayed the text, had an OK button and,
maybe,
> a Help button that could give information about the errors and warnings
> encountered.  Probably overkill at this point though :-)

Ian

Thanks for the idea - I assume it was only half serious! In fact the error
messages are quite explicit and guide the user to the right place to correct
them, so it would be overkill. But I see the general point - and I no longer
see view design as a black art, so I shall do this when appropriate.

> If you are using what the Dolphin education centre calls a "packaged
> class-based" technique (you have added a RuntimeSessionManager subclass
with
> a #main method)

In fact I am using what OA call a "packaged instance-based" technique,
because that seems easiest and gets me straight into a working app. However,
following your hint I looked around the start-up system (I would have done
it before posting the query, but I am getting close to a deadline and I was
desperate). It looks as though the best place to do the check is in
#onViewOpened for my main shell; I just put:
(Date today > expiryDate) ifTrue:
    [MessageBox notify: 'Expired'.
    SessionManager current quit.]
and it shut down as soon as I tried to open it.

Thanks for the help

Peter

Peter,

>               It looks as though the best place
> to do the check is in #onViewOpened for my main shell; I just put:
> (Date today > expiryDate) ifTrue:
>     [MessageBox notify: 'Expired'.
>     SessionManager current quit.]
> and it shut down as soon as I tried to open it.

I'm not sure (and haven't time at the moment to try it) but I think that
might not work in a application deployed using instance based deployment.
ISTR that #onViewOpened: is only called when the view is _initially_ opened,
when you are setting up the views prior to deployment for example, but is
not called on subsequent occasions, when the executable is started.

It's all a bit hazy (it's a bit too far in the dim and distant past) but I
think this is one of the reasons I settled on using class based deployment -
it makes it a lot easier to perform an action on startup.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:410f4c32$0$50920$[hidden email]...

>
> I'm not sure (and haven't time at the moment to try it) but I think that
> might not work in a application deployed using instance based deployment.

Ian

Thanks. You're quite right, of course. I was trying to cut corners, and did
not want the effort of learning about the class-based method, which looked
complicated. In fact for my application the RuntimeSessionManager is quite
trivial, and I have now changed it to work that way. I have tried it
properly, in a deployed .exe with an expiry date in the past, and it works
(as you knew it would).

Peter