HBMK2 Illegal Characters Error Msg

[Verne Tomlins]

I decided to convert a large Clipper application and immediately ran into an error I don't understand

I Downloaded and installed HB 3.0 on my Win 7 machine and  I  run Clipper 52e  in an  XP virtual machine in Win 7 pro

I planned to run hbmk2 to find out what changes I need to make to compile my application in Harbour 3.0

However..  My first attempt to use hbmk2  with file zprogs.prg produced  a set of Errors    "Illegal E0001 Character '\x10'

Clipper 52e compiles this file with no errors

Inspection of the lines identified by HBMK2 as problems gives no indication of the problem or illegal characters

attached is a zip file with the hbmk error message screen shot, and the problem section of problem code.

This is a pretty basic Clipper only section of code

Any Help would be appreciated

Thanks

 

[Klas Engwall]

Hi Verne,

[...]

> attached is a zip file with the hbmk error message screen shot, and the
> problem section of problem code.

1. It seems you forgot the attachment.
2. Better than a screen shot (and smaller too) is a log file. You can
redirect hbmk2 output to two different files like this:

hbmk2 yourproject 1>build.log 2>error.log

Regards,
Klas

[Verne]

Thks Klas,

added hbmk2 error.log to file and attached it this time

Verne

[Verne]

On Saturday, March 15, 2014 2:58:19 PM UTC-4, Verne wrote:

[Verne]

I did a little more experimenting and found the following code construct generated the error

 

 @ r1,os+c1 SAY [x ]   where x is a line drawing cross character    see attached reduced funtion code from my original program file

apparently the square brackets are not being recognized as Quotes  for the hi number ascii character

as my program does a lot of line drawing  in the DOS Screen routines,  Is there a switch or something that I can use for this ?

Thanks

Verne

[Klas Engwall]

Hi Verne,

That is an error I have never seen before, but it is the preprocessor
that doesn't like your character. \x10 is chr(16), so it is a
non-standard character that will likely not show up in a Windows font
anyway. BTW, you say high number but it is ASCII 16, so did the high bit
of the character get lost, maybe?

Anyway, the square brackets are not really the problem here. I tested
removing your chr(16) character and typing <Alt><0196> between the
brackets (that is one of the more standard line drawing characters), and
it compiled fine. So would it be possible to replace chr(16) with
another character? Or otherwise you could do a search/replace in your
editor and replace the string (including the brackets) with a regular
chr(16) function call ... but then again, I wonder if it will show up on
screen.

Another thing to consider is that the box drawing functions like
hb_DispBox() in Harbour are a better solution than SAY()-ing the box
characters because they make it possible to mix box characters from
codepage 437 with text from the CPWIN codepage (for example) on the same
screen. If you SAY() box characters when your codepage has been set to
CPWIN or CPISO they will not show up as box characters but as whatever
alphabetical character happens to have the same number in the selected
codepage. Here it is:

hb_DispBox( nTop, nLeft, nBottom, nRight, cStyle, cColor )

Styles can be found in box.ch or you can specify one single character,
and you can also specify a one-character-position box to simulate what
your xcolors.prg is currently SAY()-ing.

Regards,
Klas

[José Quintas]

If there are too many PRGs, you can use this to change to chr(16), and obtain same result:

PROCEDURE main
   LOCAL aFiles, nCont, cFile
   aFiles := Directory( "*.prg" )
   FOR nCont = 1 TO Len( aFiles )
      cFile := aFiles[ nCont, 1 ]
      hb_MemoWrit( cFile, StrTran( MemoRead( cFile ), "[" + Chr(16) + "]", "Chr(16)" ) )
   NEXT
   RETURN

José M. C. Quintas

[José Quintas]

Caution: compile using HARBOUR, because Clipper have 64kb limit for string.

José M. C. Quintas

[Verne]

maybe there's something else going on..

and I'm no longer set up with my old 32 bit programming editor 

I'm running HBM2 in a CMD window.

Notepad run in the dos window uses the ANSI Character set

Word plain text format uses the ansi  character set..  both show a line  cross in my code

My old Clipper per Reference Book  shows char 16 as a filled right arrow  and char 197 as a line cross

However..  If I use the Excel 2010 char function .. char(16)  gives the line cross

so what character set is hbmk2 using  when it loads the prg files in the win 7 cmd  window ?

either way I'm  still sure how to stop the hbmk2 error(s).. 

what are you thinking when you say a regular chr(16)  function call?

replacing [X] with chr(#)    in the @  say code ??

I'll look at your suggestion on recoding  but.. the problem is..  42 prg files with 1.5 MB of code in the application

and it's a certified Nuclear Regulatory Commission Approved Program

which  virtually rules out making significant changes to the code without a LOT of testing  required $$$$

Verne

 

[Verne]

Thank You Jose..  I might have to use that proc.. I've been away from Clipper a long time

you're taking the brackets away out and using the chr() function instead

I'm still confused though...  this program file has line drawing characters all thru it..

why did it fail on lines with that character only?

I have attached the whole file this time

Other files fail with other chars  such as '\013'

If I have to change chr(16) how many others will I have to change..

and I don't know what the screens will look like

Thanks

[José Quintas]

If you use console mode, and not change codepage, screen will be the same.

José M. C. Quintas

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Verne]

Maybe you could save me a lot of time figuring out how to use hbmk2 for this app

This is an old clipper program compiled with Clipper 5.2e and later with 5.3a and Linked with Blinker 7

I have a version with the Flipper7 Graphics Library Functionality removed

attached are two files that were used to compile and link the application

and an initial  attempt to create a compile file for hbmk2

Could you look over the .'hbp file and tell me what else might be needed in that file 

Thanks

Verne

 

[José Quintas]

I do not understand this, because can not be used clipper libraries:

-LE:\486_libs


Comparing with Clipper:

Clipper fileprg1.prg -m
Clipper fileprg2.prg -m
Clipper fileprg3.prg -m
rtlink fi fileprg1 fileprg2 fileprg3 output fileprg1.exe

hbmk2 fileprg1 fileprg2 fileprg3 -ofileprg1 -m

if used hbp file, each parameter is one line:

------- any.hbp
fileprg1
fileprg2
fileprg3
-ofileprg1
-m

hbmk2 any

Configuration:
SET PATH=%PATH%;\harbour\bin

José M. C. Quintas

[Przemyslaw Czerpak]

Hi,

This behavior is intentional.
The problem is caused by [] used as string delimiters used
after identifier.
In code like this:
? [x]
PP knows that [] are string delimiters but in code like:
? a[x]
it does not know it and have to divide [x] into tokens and
then if necessary build string from it after all translations.
In Clipper's PP it's very week thing with many different bugs
in implementation. Just simply they hacked few things to resolve
some problems without analyzing side effects.
I'm attaching small self contain example which illustrates the
problem. As you can see the line with
? [.]
is compiled correctly by both compilers (dot means chr(16)).
If you use -p switch with Clipper then you will see that only
this line is correctly preprocessed to .ppo file and all others
are wrong. It's possible because only in this case both
preprocessors know that inside [] is string so they immediately
switch to string parsing.

The wrong line
? x[.1]
is compiled without any visible errors by Clipper and only
Harbour shows correct error here.

@ row(), col() say [.]
is correctly compiled by Clipper and only .ppo file is wrong
Harbour refuse compilation because it parses [] as code. Anyhow
the cost of such decisions in Clipper causes very serious problem
in when inside [] is real code which have to be preprocessed
and legal code cannot be compiled.

Analyzing Clipper's PP behavior I decided that it's not good idea
to replicate it exactly in Harbour because I will have to replicate
also bugs. I added only few hacks which does not break other legal
code. Looks that this situation with illegal characters also can
be addressed without introducing bugs to PP so probably I'll add it
in the future. Anyhow I would suggest to simply switch to other
string delimiters and use (") or (') for strings with characters
outside accepted range.

BTW I suggest to use 3.2 from one of daily snapshots instead
of 3.0

best regards,
Przemek Czerpak

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

> Archive: /tmp/ZPROGS.pqkYTt.zip
> Length Date Time Name
> --------- ---------- ----- ----
> 94099 2014-03-15 23:13 ZPROGS.PRG
> --------- -------
> 94099 1 file

[Przemyslaw Czerpak]

Hi,

I forgot about attachment.

best regards,
Przemek

[Klas Engwall]

Hi Verne,

> maybe there's something else going on..
>
> and I'm no longer set up with my old 32 bit programming editor
> I'm running HBM2 in a CMD window.
> Notepad run in the dos window uses the ANSI Character set
> Word plain text format uses the ansi character set.. both show a
> line cross in my code
> My old Clipper per Reference Book shows char 16 as a filled
> right arrow and char 197 as a line cross
> However.. If I use the Excel 2010 char function .. char(16) gives
> the line cross
> so what character set is hbmk2 using when it loads the prg files in the
> win 7 cmd window ?

hbmk2 does not care about character sets, it is the interpretation at
runtime (of your application) that decides what will be displayed when
you tell it to SAY CHR(16), whether you use a CHR() call or use quotes
or brackets with the literal character. And that interpretation depends
on the codepage you have selected with SET(_SET_CODEPAGE), as well as
what characters are available or missing in the font used (if you do not
select a codepage, the EN codepage will be used).

But the main problem is that the preprocessor considers certain
characters illegal when placed in [] brackets. Przemek's posts explain
why Harbour differs from Clipper. He suggests that you replace the
brackets with quotes. That will absolutely solve the problem for the
preprocessor. I did not suggest it because with chr(16) and a few other
characters you will not be able to see which character you have in your
code after you have switched from the old DOS editor to a Windows editor
if those characters do not exist in the font used by the new editor. And
that can make coding error prone. But it is the quickest solution (and
in case you are not yet familiar with who is who here, you can always
count on Przemek to give you correct answers).

> either way I'm still sure how to stop the hbmk2 error(s)..
> what are you thinking when you say a regular chr(16) function call?
> replacing [X] with chr(#) in the @ say code ??

Yes, that is what I meant

> I'll look at your suggestion on recoding but.. the problem is.. 42 prg
> files with 1.5 MB of code in the application
> and it's a certified Nuclear Regulatory Commission Approved Program
> which virtually rules out making significant changes to the code
> without a LOT of testing required $$$$

Most of us in this group have very limited experience from running
nuclear plants :-) and have some difficulty deciding which changes are
significant and which are not. As I said above, replacing [X] with "X"
is definitely the quickest solution and maybe less significant than
replacing it with chr(#), considering the testing requirements.

But at the same time, using characters that cannot be viewed in the code
might also be considered a significant problem.

Regards,
Klas

[Klas Engwall]

Hi Verne,

You mentioned Harbour 3.0 in your first post. Przemek suggested moving
to a current 3.2 nightly version, and I agree. There is of course always
a small risk that bugs are introduced from one day to the next, but they
are generally found and fixed very quickly, and the Harbour core has
been very stable for a very long time now. It is the "extras" that are
under development nowadays. Just make sure to follow the discussions and
commit messages in the harbour-devel newsgroup on a regular basis and
don't use the bleeding edge for production use until it has had time to
settle for a little while. That is a safe approach, I would say.

Regarding the requirements for a lot of testing if you make significant
changes, I suspect that recompiling your code with any other tools than
your current Clipper 5.x version will be considered such a significant
change.

In your old makefile I see no /w<n> warning level. But in your .hbp file
you specify ...

# Width Unlimited
# -w0

... and then comment it out. -w is the warning level, and the default is
-w1 if not specified. I would suggest that you set it to at least -w2
since that will, depending on your coding habits, catch many
inconsistencies in the code. With less than -w2 (and absolutely with
-w0) I would not want to live next to your nuclear power plant :-)

I also see no exit severity level in either the old makefile or in the
.hbp file. Set it to -es2 to convert warnings to errors so they cannot
slip into the final .exe file unnoticed.

Regarding, the "-LE:\486_libs" line, I suppose that the libs you are
referring to there are Harbour libs, not Clipper libs (as José was
concerned about).

You might also want to set a work directory for temporary files,
although that is optional: -workdir=<directory>

But other than the warning handling I see nothing that requires
immediate attention.

Regards,
Klas

[Klas Engwall]

Hi again,

> apparently the square brackets are not being recognized as Quotes for
> the hi number ascii character
>
> as my program does a lot of line drawing in the DOS Screen routines,
> Is there a switch or something that I can use for this ?

By the way, an hour and a half ago Przemek solved that problem for you.
It will be included in the nightly binaries by tomorrow morning

2014-03-16 19:54 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
[...]
* src/pp/ppcore.c
! force stringify when illegal characters are included inside
square brackets

Regards,
Klas

[Verne]

Thank you for explaining the reason it sees an error

I already followed Klas's  suggestion to replace the offending [ ] constructs with the chr() function ( about 30 occurences in 6 program files

I will go look for Harbour Ver 3.2 . 

Almost all the screen code for this project was produced using UI and  Wallsoft's  code generator templates

I would guess the use of the [ ] delimiters in the code templates was to avoid conflicts with a developer's use of single and double quotes in their projects

So.. use of the square bracket delimiters is everywhere in the database screen IO code for this project.

I did run into another issue with a warning W0027  "Meaningless use of expression 'Logical'

I'm pretty sure it refers to this line of code and the logic is correct

IF (  ! (zrk_skipkey  .AND.   zaction == zadding) )

where all the vars relate to database screen activities in progress

I also get a long list of have a long list of "undefined reference" lines for procedures in the .prg

attached error.log ..

I'm also missing a couple of Functions that were included in Blinker

The Blinker Serial Number Function Call I will remove..

the one I need is the SwapRun()  which was used to swap memory and create a DOS window inside the application

Is there an equivalent method in Harbour ?

This screen code is pretty easy to see.  

and I'm impressed that the heavy duty array and codeblock usage in the calculations code has no issues so far.

Thanks again

Verne

[Verne]

thanks so much

Verne

[Verne]

Hi Klas,

Thanks to you experts,  I have a working 32 bit exe file

I reverted to my original files with the "illegal characters" and it compiled with none of those errors using this morning's HB32 download

Great start.. but I'm finding I'm just starting  to correct errors that Clipper let pass

Question:  Ver hb32 hinted to use  hbblink.hbc  , which I did, and that cleaned up my Blinker Function calls errors .. 

The Blinker Serial Number Function call  compiles Ok but the text var doesn't display on the screen... because it isn't entered anywhere

The Serial Number text was in the Blinker link File when using Clipper

Is there a place to add the same Serial number Text  in hbblink.hcp  or the .hcp file ?

I'm finding the initial learning curve for harbor and hbmk2 is pretty steep  with the very large selection of options available

Please pardon my dumb questions

Thanks

Verne

[Klas Engwall]

Hi Verne,

> Thanks to you experts, I have a working 32 bit exe file
> I reverted to my original files with the "illegal characters" and it
> compiled with none of those errors using this morning's HB32 download
> Great start.. but I'm finding I'm just starting to correct errors that
> Clipper let pass

Yes, that is a common experience. We usually discover that we have been
sloppier coders than we thought we were all these years :-)

> Question: Ver hb32 hinted to use hbblink.hbc , which I did, and that
> cleaned up my Blinker Function calls errors ..
> The Blinker Serial Number Function call compiles Ok but the text var
> doesn't display on the screen... because it isn't entered anywhere
> The Serial Number text was in the Blinker link File when using Clipper
> Is there a place to add the same Serial number Text in hbblink.hcp or
> the .hcp file ?

I put it on a header file that I call app.ch together with the name of
the client and the window caption and #include that header file in my
main.prg

The line in app.ch looks something like
#define APP_BLISERNUM "12345"

Then, in main.prg I have an init procedure like this:
init procedure Blinker()
hb_blivernum( APP_BLISERNUM )
return

Finally, I call BliSerNum() in my About() or wherever I need it.

I am pretty sure you can also put those #define(s) in the .hbp file (or
the batch file that runs it) with the -D option as an alternative. It
just takes a little creative thinking and a little testing. :-)

> I'm finding the initial learning curve for harbor and hbmk2 is pretty
> steep with the very large selection of options available

Yes, there are many options, but you don't need them all. Most of them
can be ignored until a specific need pops up. Standard stuff in Clipper
is standard in Harbour too. It is when you have used not completely
straightforward things in Clipper that you may have to do things
differently than before and start searching for solutions (like with the
brackets). But of course, if you recompile a large set of .prg files at
once, all the potential problems will land in you lap at the same time :-)

> Please pardon my dumb questions

N.p. so far :-)

Regards,
Klas

[Verne]

I'm sure this is an old topic but I'll submit this anyway.

There is an clipper/harbor incompatability  when a variable longer than 10 characters such as "p_sTolerance" is saved to a .mem file

The .mem file var is saved as a 10 character Variable "p_sToleran" and when it is retrieved by Harbour, the 10 character variable is not recognized as the original  "p_sTolerance"

and causes a fatal error,

attached code file

you have to run it twice..  once to create the .mem  file and a second time to read the new .mem file and cause the error

shorten the var name "p_sTolerance"  to 10 characters and the problem goes away

respectfully

Verne

 

[Klas Engwall]

Hi Verne,

> I'm sure this is an old topic but I'll submit this anyway.
>
> There is an clipper/harbor incompatability when a variable longer than
> 10 characters such as "p_sTolerance" is saved to a .mem file
> The .mem file var is saved as a 10 character Variable "p_sToleran" and
> when it is retrieved by Harbour, the 10 character variable is not
> recognized as the original "p_sTolerance"
> and causes a fatal error,

Yes, just like with field names in dbf files, the size of the
variable/field name in the file must follow the standard, which is 10
characters. Otherwise Clipper and Harbour would not be compatible.
Clipper would not understand at all if the variable names in the file
were longer than 10 characters.

Clipper truncates all variable names to 10 characters, so you can add
whatever your fingers or your short memory :-) decide to add after those
10 significant characters, and Clipper has no problem disregarding those
extra characters. Harbour, on the other hand, allows 63 characters in
variable names (this is configurable when Harbour itself is built, but
there are many variable names longer than 10 characters in the sources,
so Harbour will not build properly with a setting of 10), and they are
all significant.

Many developers run into problems with old sources where variable names
of 11 and above are inconsistent or where those long variable names are
field names with bad spelling or, as in your case, the variables are
saved in .mem files. The only solution is to hunt them down and fix them.

Regards,
Klas

[Klas Engwall]

Hi Verne,

> I did run into another issue with a warning W0027 "Meaningless use of
> expression 'Logical'
>
> I'm pretty sure it refers to this line of code and the logic is correct

> IF (! (zrk_skipkey.AND.zaction == zadding) )

> where all the vars relate to database screen activities in progress

When put into a small and simple context, it compiles just fine for me,
even with warning level -w3 set. Are you sure this is the line that the
warning is referring to? Maybe there is a context in the original code
that makes it meaningless?

> I also get a long list of have a long list of "undefined reference"
> lines for procedures in the .prg
> attached error.log ..

Third party libs?

> I'm also missing a couple of Functions that were included in Blinker
> The Blinker Serial Number Function Call I will remove..
> the one I need is the SwapRun() which was used to swap memory and
> create a DOS window inside the application
> Is there an equivalent method in Harbour ?

We solved BliSerNum() in another sub-thread. Did you solve the swapping
in the mean time? The function you are looking for is probably
SwpRunCmd(), and it exists in the hbblink contrib. It is only a wrapper
for HB_Run(), and it ignores everything except <cCommand>, the first
argument. After stepping out of the 16-bit environment there is no need
to swap memory any more.

Regards,
Klas

[Verne]

Hi Klas,

Maybe I wasn't clear on how I stated the issue

The Harbour compiled code writes  a 12 character variable to a .mem  file  as a 10 character variable.

The same Harbour exe then reads the mem file but doesn't recognize the 12 character var it wrote to the file because it reads only a 10 character var from the .mem file.

If it's just a  question of coding standards to maintain compatability for old clipper apps used concurrently with harbor apps,   ..  enough said

Verne

[Przemyslaw Czerpak]

On Mon, 17 Mar 2014, Verne wrote:

Hi,

> Maybe I wasn't clear on how I stated the issue
> The Harbour compiled code writes a 12 character variable to a .mem file
> as a 10 character variable.

Because .mem file format does not support longer names.
We have to keep binary compatibility in .mem files for
existing programs which needs compatibility with existing
.mem files and/or exchange them with Clipper applications.

> The same Harbour exe then reads the mem file but doesn't recognize the 12
> character var it wrote to the file because it reads only a 10 character var
> from the .mem file.
> If it's just a question of coding standards to maintain compatability for
> old clipper apps used concurrently with harbor apps, .. enough said

If you want to use memvars with names longer then 10 characters
and save them to file you have to use different format.
Harbour uses .hbv files for it.
To use them it's enough to change:
SAVE [ALL LIKE|EXCEPT] ... TO ...
RESTORE FROM ...
to:
SAVE HBV [ALL LIKE|EXCEPT] ... TO ...
RESTORE HBV FROM ...

best regards,
Przemek

[Pritpal Bedi]

Hi Verne

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

I started using hb30 hbide  but haven't figured out ound how to get the help panel to show the documentation..  BTW.. hbide wasn't in the hb32 nightly

If I get that working maybe I won't have to bother you so much  :)

-----------

Unfortunately, HbIDE is not part of Harbour binaries as it used to be.

IF hb32 nightly is installed in C:\hb32 folder

   Look for if .hbd files are present in c:\hb32\doc 

   IF YES

      Navigate to : HbIDE->Setup->HbIDE Setup->Paths->Harbour Root

      Input:  C:\Hb32

      Press <Ok>

      Click <Harbour Documentation> icon.

      Explore the Interface

Pritpal Bedi

[Verne]

That worked..  I was trying to use the help icon rather than the Documentation  item..

Thanks

[Verne]

Hi Klas,

Please disregard my last question about numeric  calculation differences between Clipper 5.3 and Harbour

My mistake.. looked at a wrong output file   my numeric calculation results from clipper and Harbour are identical.

Verne

[Klas Engwall]

Hi Verne,

> an update and some more questions
> The W0027 Logical warning went away .?? for now anyway :)
>
> Adding the hbblink.hbc resolved the Blinker SwapRun call error and the
> old code ran correctly with no changes needed. (optimize it later as
> suggested by Przemek )

There are several ways to do this. SwpRunCmd() and hb_Run() do it
identically. Then there is the Windows specific wapi_ShellExecute()
which I use most of the time, and probably one or two other options that
I can't remember off the top of my head. The choice depends on how you
want the OS to behave, among other things.

> mem file vars: I shortened the variables in the code to less than 10
> characters so the ,mem files work correctly (and todo notes to change
> to hbv files)

OK

> I started using hb30 hbide but haven't figured out ound how to get the
> help panel to show the documentation.. BTW.. hbide wasn't in the
> hb32 nightly
> If I get that working maybe I won't have to bother you so much :)

I noticed that Pritpal jumped in and told you how to use it, but I
believe he forgot to mention where to go to find it. Here it is:
http://sourceforge.net/projects/qtcontribs/

But you have to be aware of the fact that the docs in the .hbd files
(and the .txt files in the same directory) are old, outdated and
incomplete. The biggest problem the Harbour community has is that nobody
has had the time to write any new docs in many years. José started a
documenting project a couple of weeks ago. I can only hope that he comes
out of it alive at the other end :-) because it is a huge project.

One place to go online to read the same docs as the ones in the Harbour
tree plus a list of all existing function names, etc, is at Giovanni's
site (to just mention one of several similar alternatives):
http://www.elektrosoft.it/tutorials.asp

> Is there any reason you might expect different numeric calculation
> results in Harbour than in a Win XP Clipper 5.3b installation ?
> I'm getting differences in the 4th and 5th decimal places after only a
> few iterations.

The most complicated numerical calculations I do is adding VAT to
invoice totals :-), so I never see more than two decimals. I don't know
enough about floating point calculations to give you a technical
explanation, but I would expect Harbour to be more reliable. Przemek is
your guy ...

> The software models a building and calculates heat transfer between the
> rooms in the building.
> It loads all the building configuration data from the databases into a 6
> or 7 level array matrix and then calculates the room temperatures
> as time passes. It uses decimal second intervals over a specified period
> of hours or days so a calculation differences in a few iterations is
> serious.
> I have a set of benchmark projects used to verify correct results on a
> new installation
>
> I'm thinking of differences like the old numeric processor floating
> point problem Delving into the calculation codeblocks could be murder
>
> Any ideas

Not really, except that floating point math is very different from
calculating real numbers and that the result will vary between serial
calculations using/not using intermediate values, for example.

I found a discussion at Stack Overflow about differences between MinGW
and VS C++ with a couple of guesses why it might be like that. There the
difference showed up in the 14th decimal, and I suppose that after a few
iterations of the same precision difference it will move up to more
significant decimal places. Anyway, here it is:
http://stackoverflow.com/questions/13447444/what-difference-between-vs-c-and-mingw-to-implement-double-type

Regards,
Klas

[Verne]

Hi Klas

Now that my head has stopped spinning from that Math Site you pointed me to..  :)

I have a question on the use of the contrib code like hbblink  

..  going back to the BLISeriaLNum() function... 

hbblink took care of my SwapRunCmd() with no changes to my code

I looked up the return var name for BLISeriaLNum() in the hbblink code 

FUNCTION BliSerNum()
   RETURN s_cSerialNum

that blinker.prg  file declared

  STATIC  s_cSerialNum := ""

So I added

#define  s_cSerialNum   "MyText"

 to a definition File called in my main.prg  file

That didn't work for the  var = BliSerNum( ) call..    I got var = "" ...nothing

  however  If I  used the defined name in  

var = s_cSerialnum   instead of the function call..  I got  var = "My Text" 

Guess I don't understand quite how  hbblink  in the hbmk2 file works

 var  scope ? 

thanks

 Verne

[Klas Engwall]

Hi Verne,

> Now that my head has stopped spinning from that Math Site you
> pointed me to.. :)

I did? Oh, that must have been the Stack Overflow discussion about
different floating point implementations in different compilers. Sorry
about that :-)

> I have a question on the use of the contrib code like hbblink
> .. going back to the BLISeriaLNum() function...
> hbblink took care of my SwapRunCmd() with no changes to my code
> I looked up the return var name for BLISeriaLNum() in the hbblink code
>
> FUNCTION BliSerNum()
> RETURN s_cSerialNum
>
> that blinker.prg file declared
>
> STATIC s_cSerialNum := ""
>
> So I added
> #define s_cSerialNum "MyText"
> to a definition File called in my main.prg file
>
> That didn't work for the var = BliSerNum( ) call.. I got var =
> "" ...nothing
> however If I used the defined name in
> var = s_cSerialnum instead of the function call.. I got var =
> "My Text"
>
> Guess I don't understand quite how hbblink in the hbmk2 file works
> var scope ?

In blinker.prg there is also a function called hb_BliVerNum() which is
where you *set* the value of the static variable. As I mentioned in the
other sub-thread you will have to send the value of your #define from
your main.prg to the hb_BliVerNum() function. To begin with, mixed case
#defines are both error prone and easily misunderstood by the human
reader. And the s_ prefix is to tell the human reader that it is a
static variable, which it is not in the .prg where you try to use it. So
change it to something that is all upper case, like

#define APP_BLISERNUM "MyText"

(I already used that name when I wrote about it last time, so I use it
again for consistency).

Then, still in main.prg, after your main() procedure, add an init

procedure like this:

init procedure Blinker()

hb_BliVerNum( APP_BLISERNUM )
return

This will load the value of the #define into the static variable in
blinker.prg. And then you can call BliSerNum() from anywhere in your
application.

You can of course call hb_BliVerNum() without an init procedure, but it
is a good practice to set up things like that in a separate part of the
source code to make it easy to find. And, more importantly, the init
procedure will be called before your main() procedure is called, so the
serial number will be available from the very beginning.

One more note about <s_cSerialnum>: In blinker.prg it is a file wide
static, which makes it visible to all functions in that .prg file. But
no other .prg file knows that it exists. So it makes no sense to your
main.prg, and that is why you have to call the hb_BliVerNum() and
BliSerNum() functions, which both exist in blinker.prg, to set or get
its value from anywhere else.

Regards,
Klas

[Verne]

Hi Klas,

Finally got it.. Thanks for the detail

Verne