Issues

[NewsArchive]

I have come across 3 significant issue in the course of my latest round of
install prep.

1. I made a mistake and omitted a data conversion program.... (I omitted 1
out of 7, which was installed at the last minute, naturally! <g>)
I *did* remember to 'code-sign' them all.... but I 'Install File'd only 6
of the 7.
However, I did remember to 'Run Program' all 7 .. (whoops...)
But when it ran on a client's site, it did NOT warn that "MVD_conv/exe"
'could not be found' (or similar).
It gave the impression that all converters ran ok.... caused a bit of
confusion.

I believe this is a mistake - if I wanted the Run to be conditional on the
presence or otherwise of a program, I would have use "if exists"
If I Run it, I expect it to be there, and would expect a warning if not...
no silent operation required here!


2.While debugging I notice that script execution is always ONE STEP AHEAD of
the cursor!
IOW, when I arrive on a code line, that line has *already* just executed.
Clearly this is non standard debugger behaviour.


3. While debugging I wanted to check help.
I pulled it up ok, but tried to use the index - it wouldn't go anywhere..
and when I tried to close the help system, the whole of SB shut down,
MID-debug.


HTH
Steve

[NewsArchive]

Steve,

> I have come across 3 significant issue in the course of my latest round of
> install prep.
>
> 1. I made a mistake and omitted a data conversion program.... (I omitted 1
> out of 7, which was installed at the last minute, naturally! <g>)
> I *did* remember to 'code-sign' them all.... but I 'Install File'd only 6
> of the 7.
> However, I did remember to 'Run Program' all 7 .. (whoops...)
> But when it ran on a client's site, it did NOT warn that "MVD_conv/exe"
> 'could not be found' (or similar).
> It gave the impression that all converters ran ok.... caused a bit of
> confusion.
>
> I believe this is a mistake - if I wanted the Run to be conditional on the
> presence or otherwise of a program, I would have use "if exists"
> If I Run it, I expect it to be there, and would expect a warning if not...
> no silent operation required here!

Not sure if I understand correctly what you mean with "mistake" here. If
you mean "it was Steve's mistake", then yes <g>. You have to check the Run
Program error code (at runtime) to see if the execution was successful. For
example, enable the ShellExecuteEx checkbox and if it returns -1 then the
program was not there.

If I misunderstood your question/comment, please let me know.

> 2.While debugging I notice that script execution is always ONE STEP AHEAD
> of the cursor!
> IOW, when I arrive on a code line, that line has *already* just executed.
> Clearly this is non standard debugger behaviour.

Unfortunately, we can't reproduce this. Do you have a simple project (that
we can compile here) to demonstrate the problem?

> 3. While debugging I wanted to check help.
> I pulled it up ok, but tried to use the index - it wouldn't go anywhere..
> and when I tried to close the help system, the whole of SB shut down,
> MID-debug.

We'll check this, thank you.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> 2.While debugging I notice that script execution is always ONE STEP AHEAD
> of the cursor!
> IOW, when I arrive on a code line, that line has *already* just executed.
> Clearly this is non standard debugger behaviour.

I re-read your message. I think I see what you mean. Please see attached
screenhot. The debugger arrived on Line 35 and has already executed (and
the value of the changed variable is displayed in the Variables list). This
is by design.

Friedrich

[NewsArchive]

I say that Run Program should automatically throw a dialog on error.

It should NOT be necessary to check any error code.

For mine, the best option would be to have a check box on the Run dialog to
show/suppress the error message.

Steve Bywaters

[NewsArchive]

> I say that Run Program should automatically throw a dialog on error.
>
> It should NOT be necessary to check any error code.
>
> For mine, the best option would be to have a check box on the Run dialog
> to show/suppress the error message.

So the Clarion RUN() command or ShellExecuteEx() Windows API throw a dialog
on error?

Check the %_SB_ERRORCODE% value and you are done. There are quote a few
hundred script functions in SetupBuilder. Only you (the developer) can
decide what a critical error is (in your project).

Hope this helps.

Regards,

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

"quote a few hundred" should read "quite a few hundred"

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Or, of course, you could simply add another checkbox option (adding to the 4
below) saying:
"Show dialog on error:" (or similar)

Steve Bywaters

[NewsArchive]

> Or, of course, you could simply add another checkbox option (adding to the
> 4
> below) saying:
> "Show dialog on error:" (or similar)

To all available functions (INI File, Shortcuts, Services, Registry,
etc.)??? Not a good idea.

Again, only check %_SB_ERRORCODE% and you are done (and it gives you all the
flexibility needed). You can detect the error code and then decide what to
do (e.g. wait and try it again, or run another program based on the error
code, and so on).

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

>To all available functions (INI File, Shortcuts, Services, Registry,
e>tc.)??? Not a good idea.

No, to items like Run - whee I expected the target to be there.
If I DIDN'T want an error flag, then I would have enclosed in If Exists


> Again, only check %_SB_ERRORCODE% and you are done (and it gives you all
> the flexibility needed). You can detect the error code and then decide

If I *knew* I didn't have the item installed, then I would not have made the
mistake in the first place!

If I follow your guide, I will have an errorcode check after each script
line, 'just in case'.. which seems nonsense to me - that would produce
over-long/bloated scripts.

Isn't the object of the installer to make creating as simple as possible?
My point being that a default of an error dialog, with option to do
otherwise, gives the best of both worlds.

However, in short - I feel that error on a Run should by default produce
an error - but you don't.... That's ok.

Steve Bywaters

[NewsArchive]

This is completely NON-standard debugger behaviour!

(Even the Clarion one doesn't work like that)

Steve Bywaters

[NewsArchive]

> This is completely NON-standard debugger behaviour!
>
> (Even the Clarion one doesn't work like that)

But it's how the SetupBuilder script-debugger was designed and works for
more than five years now.

Regards,

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

So the logic of: "I'll just go to this line of script and see what effect it
has on this variable".... OOOPS - "it's value is already changed" - doesn't
bother you? ;-))


Now if Visual Studio worked like that I really would be in trouble!!

S.

[NewsArchive]

Steve,

> >To all available functions (INI File, Shortcuts, Services, Registry,
> e>tc.)??? Not a good idea.
>
> No, to items like Run - whee I expected the target to be there.
> If I DIDN'T want an error flag, then I would have enclosed in If Exists

So the same would be the case for 80% of all functions, like Shortcuts,
Services, ODBC Config, Text File Operations, Set File Attributes, Rename
File, etc. where the developer expects the target to be there.

> If I follow your guide, I will have an errorcode check after each script
> line, 'just in case'.. which seems nonsense to me - that would produce
> over-long/bloated scripts.

No. You use an errorcode check for fatal errors. But you have to decide
what a fatal error is. For the installer, only "Install File(s)" and
"Create Directory" (directory not writable) errors are fatal installation
errors. For you, a "Run" error is a fatal error, so check for the
errorcode.

> Isn't the object of the installer to make creating as simple as possible?

Yes. And that is the case here (IMO). As simple and as flexible as
possible.

> My point being that a default of an error dialog, with option to do
> otherwise, gives the best of both worlds.

For you, an error dialog for the "Run" function is important. For another
developer, it might be an error dialog for the "Get Atomic Clock Time" or
the "Edit INI File" function. That's why we introduced the %_SB_ERRORCODE%
functionality. You (the developer) can decide where and when to check for a
return code.

If you "wait" for a program and this program returns an exit code, you can
decide what to do with the exit code.

> However, in short - I feel that error on a Run should by default produce
> an error - but you don't.... That's ok.

Don't get me wrong. I am always open for suggestions (and 99% of all
suggestions make it into a SetupBuilder release), but an error dialog on
"Run" does not make much sense to me.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Fine - then just add a check box to EVERY script function that can return an
error:

* "display error dialog" (y/n) - default 'n'

* IF 'y' then generic error dialog: "The 'Atomic Clock' command at script
line 123 failed to execute, with errorcode 2"

* if script-writer is more fussy about the nature of the critical dialog
then they can leave at 'n' (default) and still create their own, as per your
suggestion.

* but for normal use, this gives are *very* quick way of protecting every
(esp. file-based) instruction with a feedback dialog - without having to a)
test an errorcode and b) create a message/dialog!!!!! i.e. its AUTOmatic
if you just check the box... which is what I'm trying to get to.


The Prosecution rests...

Steve Bywaters

[NewsArchive]

Steve,

Thank you for your suggestions.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner