Best way to update RED file using SB 6.6 Developer

[NewsArchive]

(This all applies to Clarion 6 and earlier)

I assume I would use Get INI Value/Set INI Value for updating the RED
file on the target system. (This is what I have been doing in Wise)

Before doing that, my script needs the name of the RED file. I think in
most versions, the exename value in WIN.INI is the same as the red file.
That part seems easy. But, which section of the INI? Anybody know an
easy way to get this from SB? Or, maybe the exename (or redname) more
directly?

On my system, the Clarion Environment Detection function returns
"Clarion 6.3" in variable %_SB_RETURN%. But, the INI section is
"Clarion 6.0".

In Wise scripts, I have been using a separate program to find all
installed versions in WIN.INI, but had hoped Setupbuilder would make
that unnecessary.

One other thing. Where in the script do I pick up the return value from
the Clarion Environment Detection dialog? The return value goes into
%_SB_RETURN%. This value appears to be set by other functions, as well,
including other dialogs. Dialogs are defined in a declarative section,
and there seems to be no way to synchronously capture return values.

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

I guess I stumped Friedrich. :-)

Looks like what I need to do is set up a pretty elaborate include script
that enumerates the possible responses from Clarion Environment
Detection, and calls "IF Clarion" with appropriate arguments to access
the exe path, then parses out the name returned by IF Clarion:

pseudo Clarion/SB script:
CASE %_SB_RETURN% ! from Clarion Environment Detection
...
OF 'Clarion 6.3'
IF system does have Clarion 6.3 (EE)
set variable %exefile% to %_SB_TMP%
END
IF system does have Clarion 6.3 (PE)
set variable %exefile% to %_SB_TMP%
END
OF 'Clarion 6.2'
etc.
END
set variable exename to function:extract file(%exename%)

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

I wrote the include script along the lines of my last post. It was
easier than I expected. Sure beats having to install a giant EXE to do
this stuff. :-)

Still...would be better if Clarion Environment Detection put the exename
value (from the INI file) into a predefined variable. Actually, WIN.INI
has root, bin, exename, and workdir. All of these would be nice to have
as results. Friedrich?

(Don't you hate Clarion 3rd party?)

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

> I wrote the include script along the lines of my last post. It was
> easier than I expected. Sure beats having to install a giant EXE to do
> this stuff. :-)

Hi Phil,

I did an interesting thing with my new PageSnip product and SetupBuilder.

I have a post installer that runs (in the user account mode) after the
install reboots (which is required since it installs the Tracker PDF
driver).

This Configuration Wizard helps the user decide where they want to have the
data (making CSIDL recommendations), if it is shared or private, how the
program runs on startup, all about shortcuts, etc.

The entire EXE (created by SetupBuilder) is 157K.

;-)

So the next thing I did was to put a ShellExecute statement on a pulldown
menu in the main Clarion app to re-run this wizard if the user wants to
make changes to any of those settings.

The result was a two-fold benefit:

1) I only had to write the code ONE time (instead of doing it in
SetupBuilder for the install - then again in Clarion

2) The user experience is exactly the same during the install - or later if
they reconfigure.


Plus dealing with the issues of controlling the program and data was far
easier in SetupBuilder than it is in Clarion.

I'll definitely be repeating this sort of thing in the future.


BTW - "Thanks Friedrich" for making all this possible!

;-)

Charles


--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

The scripting language in somewhat weird, but only slightly more weird
than Wise (which I have been using for years). The main thing I have
had trouble dealing with in SB scripting is that dialogs are treated as
declarative, and there doesn't seem to be a way to reliably synchronize
them with executive statements. (Maybe I just haven't mastered the
technique.)

Wise has only the "Parse String" statement for string manipulation which
is essentially the "split source string" actions of the SB Handle String
function. You can do just about anything with parse if you are clever,
but the extra stuff in Handle String just makes it so much easier with
fewer statements.

With all the Clarion-specific stuff in the script, looks like my
installs will shrink from about 2 megs to maybe 200K.

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

Hi Phil,

> The scripting language in somewhat weird, but only slightly more weird
> than Wise (which I have been using for years). The main thing I have
> had trouble dealing with in SB scripting is that dialogs are treated as
> declarative, and there doesn't seem to be a way to reliably synchronize
> them with executive statements. (Maybe I just haven't mastered the
> technique.)

See attached screenshot. It's very easy and you have completel control over
the dialogs. You define all dialogs the user might see. Then you can
hide/display dialogs dynamically at runtime, you can execute statements from
within the Loop Wizard, etc.

> Wise has only the "Parse String" statement for string manipulation which
> is essentially the "split source string" actions of the SB Handle String
> function. You can do just about anything with parse if you are clever,
> but the extra stuff in Handle String just makes it so much easier with
> fewer statements.
>
> With all the Clarion-specific stuff in the script, looks like my
> installs will shrink from about 2 megs to maybe 200K.

Cool!

Friedrich

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

"point. click. ship" - that's SetupBuilder 6.6
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

>
>I guess I stumped Friedrich. :-)
>

No :-)

Our office is closed during the US Thanksgiving holiday. We will resume our
normal office hours on Monday.

Friedrich

[NewsArchive]

By the way, your "Get Clarion Names" include script is great! :) Very well
done.

Friedrich

[NewsArchive]

I understand. The only reason I said that was that I noticed some
responses to other posts later than mine.

Thank you for the compliments on the script. This seemed an easier
approach than trying to match up an entry in WIN.INI. Also, I am not
sure about accessibility of WIN.INI in Vista.

I believe some earlier versions of Clarion did not use the same name for
the exe, red, and ini. But, those versions are so antique at this
point, I don't support them at all, so did not bother with them in the
script.

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

Phil,

> I understand. The only reason I said that was that I noticed some
> responses to other posts later than mine.

Yes, you are right. I had to switch back and forth between newsgroups,
sales, consulting, and so on and so on and just ran out of time. But
answering your (specific)question was still on my To-Do list :)

> Thank you for the compliments on the script. This seemed an easier
> approach than trying to match up an entry in WIN.INI. Also, I am not sure
> about accessibility of WIN.INI in Vista.

The installer can access/read the WIN.INI under Vista and Windows Sever 2008
without any problem. But, if the Clarion 6 user did not apply the "C6 Vista
fix", then there are no WIN.INI entries for C6.

> I believe some earlier versions of Clarion did not use the same name for
> the exe, red, and ini. But, those versions are so antique at this point,
> I don't support them at all, so did not bother with them in the script.

Good idea. I think I still have a list of RED files for older Clarion
versions in the office. Just let me know if you need the list and I'll try
to find it.

Friedrich

[NewsArchive]

Friedrich,

I finally discovered the variables %_SB_DIALOGID% and
%_SB_DIALOGNEXTID% yesterday in another thread while searching for
something else.

The attachment shows my solutions to several fundamental problems, by
using these variables and some other not quite obvious techniques.

A. There are two radio button dialogs, one dependent on the other. The
wizard loop shows or hides the 2nd of these depending on the option
chosen by the first. I needed both the show and the hide to support
user backtracking in the dialog loop. (A subtlety initially lost on me)

B. If the dialog text is changed on one radio button dialog, it is
changed for all radio button dialogs. This drove me nuts until it
occurred to me if I use a variable for the entire dialog text, and swap
different constants into the variable depending on the next dialog to
display, then each radio dialog can be different. The dialog constants
are defined as Compiler variables. Whew.

C. The Get Clarion names include script I designed solved the problem
of finding Clarion RED and INI files. (The original subject of this
thread)

(I will spare you the long lecture on how and why A and B were much
easier with Wise. :-) )

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

Phil,

> B. If the dialog text is changed on one radio button dialog, it is
> changed for all radio button dialogs. This drove me nuts until it
> occurred to me if I use a variable for the entire dialog text, and swap
> different constants into the variable depending on the next dialog to
> display, then each radio dialog can be different. The dialog constants
> are defined as Compiler variables. Whew.

All dialogs make (by default) use of text resources, not compiler variables!
SetupBuilder is a multiple-language system and text resources make it very
easy to handle this.

For examle, the "Welcome" dialog has #DLG_WELCOME_TITLE# in the title field.
This resolves to "Welcome" in English, "Bienvenue" in French, "Welkom" in
Afrikaans, etc.

If you have more than one Radio Buttons (or whatever) dialog and you need
different text messages, you can create your own text resources ("Text and
Messages" Visualizer) or use variables or plain text. You can even use he
same text resource in different dialogs/fields.

Text resources are very handy if you have to create a multiple-language
installation (and quite a few developers have to) because *one* text
resource defines the text for *different* languages.

> C. The Get Clarion names include script I designed solved the problem
> of finding Clarion RED and INI files. (The original subject of this
> thread)
>
> (I will spare you the long lecture on how and why A and B were much
> easier with Wise. :-) )

But to be frank, I would be eager to hear from you why B was much easier
with Wise :) You can use plain text in each and every dialog (if you want).
Instead of using the pre-defined #DLG_RADIOBUTTONS_TITLE# text resource in
the second, third, etc. radio dialog, just enter "Select Second Option" and
you are done. Or use a runtime variable or even a compiler variable.

Friedrich

[NewsArchive]

> But to be frank, I would be eager to hear from you why B was much easier
> with Wise :)

You must understand, I am used to filling in what is shown in the
attached screen shot. :-)

(I include both the dialog and the help topic that pops up when I click
F1 in the dialog)

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

Friedrich,

Your points are all well taken. I totally overlooked that visualizer.
In particular, I overlooked the ability to create my own named text
resources using the visualizer. A very powerful tool.

> You can use plain text in each and every dialog (if you
> want). Instead of using the pre-defined #DLG_RADIOBUTTONS_TITLE# text
> resource in the second, third, etc. radio dialog, just enter "Select
> Second Option" and you are done. Or use a runtime variable or even a
> compiler variable.

Ahh. I see now. I thought those fields could only contain resource
names. It didn't occur to me I could simply type text or use a variable
instead of a resource name. Instead, I have used the ID= button on each
dialog in order to change the text to display for that dialog. Which, I
now realize, changes the content of the named text resource, and that
content shows up everywhere that resource is used. No problem until I
had a second radio button dialog.

My simple-minded solution was to plug a variable into the definition of
the resource.

I will get the hang of this eventually. :-)

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

Seems my use of SB Get INI/Set INI to update an RED file is not working
out so great. To put it mildly! :-(

Just discovered (actually my customers discovered, ouch!) that SB replaces:
*.* = .; %root%\whatever

with:
*.* = .; \whatever

Which renders Clarion inoperable until the customer restores the RED file.

What is the normal method of editing the RED file with SB?

(Sure wish I could have been set straight when I first mentioned it on
this thread a couple of months ago)

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

can reproduce this here with Build 2083. Definitely a "Get INI Value..."
bug.

Item in review!

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

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Actually, I am using:
Set variable %editline% to Function:Get INI Value
(*.* line in the common section)
...
Edit INI File
(replacing *.* with %editline% and additional stuff)

Evidently, SB is interpreting the contents of the %editline% string var,
and replacing the %root% with null. How do I escape the string variable
so that SB does not interpret its contents? I want the string verbatim.

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

Do you have SetupBuilder 6.7 Build 2083?

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

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Turns out Get Ini is useless anyway, as the value is limited to 255
characters, and SB simply truncates any excess. Some users have massive
RED lines. What is the reason for that ridiculous 255 limit? My Wise
scripts have handled every RED file ever thrown at them (using INI
functions).

I guess file I/O is my only option here. The script just gets ever more
complicated. Sigh.
--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

I checked this with SB67 but there is no 255 byte limit here. I can read
1,024 bytes in a line.

Friedrich

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

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

I have 6.7.2083 installed.

I have attached a testcase. Observe the before and after of editing *.*
in the [Common] section.

Notice that besides killing all of the existing macro references, the
original line was truncated following "prod2\template;". It appears
from this that Get INI first truncated to 255, then threw away the
macros after that, resulting in something like approximately 170 of the
original 500+ characters in the variable.

I hope you can fix this quickly. I am pretty frantic about this one.

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

It's not a 255 byte limitation per-se. The %root% item causes the problems.
The installer interprets %root% as a variable (complete nonsense).

Sorry to hear that you are pretty frantic about this one.

Regards,

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

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

My installer causing my customers to not be able to launch Clarion makes
me look really bad. "If he can't the install right, what must the
product be like?" It takes a long time to reestablish trust after that.

The choices I am left with at this point are all bad. I guess the the
least bad choice I have at this point is warn new customers to not let
the installer update the RED because SetupBuilder is broken. Which
means, they have to manually do that step, and then manually register
the templates. Error prone, leading to more problems. Or they will not
notice my warning and I will be back to the first problem.

I should have checked the results of the install better before giving it
to customers, but it was not the kind of bug I expected in a product in
its 7th version, that is supposedly used by almost all 3rd party
vendors. Clearly, all the 3rd parties using this tool are not really
"using" it, if I am the first to run across this.

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

I think most 3rd parties do not use the "Get INI" function to handle RED
file manipulation. And 99.99% of all other SetupBuilder users never run
into this very specific situation. So it has nothing to do with "they are
not really using it". ABSOLUTELY NOT! Believe it or not, this is a very
minor issue (that causes you problems, which of course is bad and I am sorry
for that). It's a regression and it can happen. I don't like it (no, I
hate it), but it happens from time to time. It will even happen in its 8th
version. It took only 30 seconds to fix the issue - the fix will be part of
the next SetupBuilder update.

You have several other (good) choices, but feel free to warn your users that
SetupBuilder is "broken".

Regards,

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

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

A missing ',' in a navigation program lost a rocket in the early space
program. "Minor error" for the programmer. "Disaster" for the launch.
Which is to say, we have different perspectives. ;-)

An RED file is structured identically to an INI file, and I would bet a
steak dinner the IDE uses INI functions to read it. (Else, why design
it with an INI structure?)

The name of this thread is "Best way to update RED file using SB...". I
don't know how to be more explicit than that with a query. I opened
this thread in November. This is now January. You now say I have many
better options, but I still haven't heard a single recommendation from
you of a better way to manage an RED file. You say you believe most 3rd
parties do not use the "Get INI" function to handle RED file
manipulations, and based on my experience, I would bet NONE use it.
That was really my point. But, I still have not heard what they
actually do. Maybe write their own program, which has to be called at
install time? Just exactly what I wanted to eliminate by switching to
SB from Wise.

If you know a better way, I am very coachable. :-)

I am overjoyed the fix was so easy and will be in the next update. I
can't wait to get my hot little hands on it. The single most valuable
part of SB is your responsiveness to problems. (Both user error and SB
bugs) The main reason I have fought my way thru a steep learning curve
and several issues, and stuck with it!

--
Phil Carroll
http://www.enablingsimplicity.com

[NewsArchive]

It's not caused by a 255 byte limitation. The %root% item causes the
problems. The installer interprets %root% as a variable (complete
nonsense).

Sorry to hear that you are pretty frantic about this one.

Regards,

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

"point. click. ship" - that's SetupBuilder 6.7
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

I don't understand how the %root% problem causes the end of the line to
be thrown away, but I guess I will take your word for that. You have my
test case.

--
Phil Carroll
http://www.enablingsimplicity.com

friedrich linder wrote:
> It's not caused by a 255 byte limitation. The %root% item causes the
> problems. The installer interprets %root% as a variable (complete
> nonsense).