Weird GPF Crash

Dear Friends,

Enviro:  a protected mode app (with Packcode, Packdata, and Compress in the
.lnk file) using Clipper 5.2e and Blinker 5.1

After an hour of testing/fixing I have resolved a weird GPF.

I was making extensive changes in a tbrowse module (shopbrow.prg), and after
quite a few changes, compiled the app (approx 76 modules).

The compile was successful.

When I started up the app, I got an immediate GPF !! (I didn't even get into
the main menu !)

After a bunch of work (i.e., checking the new code against a back up copy,
and gradually building the new module again, I finally got to an innocuous
assignment statement that cause the crash:

dSAVCHKDTE := CHEKDATE      // dSAVCHKDTE is a private vrbl

Removing this statement resolved the GPF but caused me terrible confusion.

After much more work I made the dSAVCHKDTE a LOCAL vrbl and this removed the
GPF.

Can anybody explain this GPF cause & cure to me ???

BTW, I went over the whole module again, and 'LOCALized' all the vrbls that
I possibly could, and I'm back-in-action again after a 'terrifying' morning 
(I
'terrify' easily these days :))  )

TIA,

-Mel Smith

Mel

>   Can anybody explain this GPF cause & cure to me ???

Clipper is prone to have such "mysterious" issues, once you reach certain
application size, or memory utilization. I'd strongly urge you to recompile
your application with xHarbour (http://www.xHarbour.org), to rid yourself
from all such restrictions.

Ron

Ron,

Thanks !

Moving to xHarbour is at the top on my list, and I have started moving this
app tentatively to xHarbour over the past two months -- but I still like
Clipper as my 'warm blanket' :))

Also, my customer is still hitting me with new changes required nearly daily
in this and four other apps (and I get paid  to satisfy these needs first).

Thanks again,

-Mel Smith

Mel,

>   Moving to xHarbour is at the top on my list, and I have started moving
> this
> app tentatively to xHarbour over the past two months -- but I still like
> Clipper as my 'warm blanket' :))

Recompiling Clipper console application with xHarbour should be fairly
transparent process. The most obvious issue is having to address misspelled
Symbols (when longer than 10 characters). Please feel welcome to report any
difficulty you encounter.

Ron

Ron,
Have been thinking of moving to xHarbour for some time but have a couple of
concerns that I can't find answers to on your website or in the Clipper NG.
(Maybe I'm looking in the wrong place!)
- the application I need to port uses a number of external libs e.g.
Silverclip, Funcky and Clipper Tools.  Will I still be able to call these
functions or will I need new libs with similar functionality to compile and
link with xHarbour?
- I have a small amount of C code that has been compiled to an .obj with the
Microsoft V5.1 ( I think ) compiler.  Will I still be able to link it with
Llibce.lib, or will it have to be rewritten?

Thanks for the help.
--
Rob Grattan
R&D Software Pty. Ltd.

Rob

> Have been thinking of moving to xHarbour for some time but have a couple
> of concerns that I can't find answers to on your website or in the Clipper
> NG. (Maybe I'm looking in the wrong place!)
> - the application I need to port uses a number of external libs e.g.
> Silverclip, Funcky and Clipper Tools.  Will I still be able to call these
> functions or will I need new libs with similar functionality to compile
> and link with xHarbour?

I'm not familiar with SilverClip, Funcky is available as OLE Server, and
most functions of Clipper Tools are available.

> - I have a small amount of C code that has been compiled to an .obj with
> the Microsoft V5.1 ( I think ) compiler.  Will I still be able to link it
> with Llibce.lib, or will it have to be rewritten?

C code for Clipper in most cases needs just to be recompiled, with  minor
S&R modification.

Ron

Ron,
Thanks for the prompt reply.  As usual, answers prompt more questions...:

- Silverclip is a Comms library for accessing the Serial Port/modems.  I
think there are comms functions in Clipper Tools so I should be ok?
- Not sure what you mean by recompiling the C code - recompiling with what -
a later version of the Microsoft C compiler?
- Sorry - S&R?  Syntax and ??  Could you elucidate?
--
Rob Grattan
R&D Software Pty. Ltd.

Rob,

> - Silverclip is a Comms library for accessing the Serial Port/modems.  I
> think there are comms functions in Clipper Tools so I should be ok?

The commercial version of xHarbour from http://www.xHarbour.com includes
CT3Comm.lib which offeres all the functionality of the CT3 comm functions.

> - Not sure what you mean by recompiling the C code - recompiling with
> what - a later version of the Microsoft C compiler?

If using the commercial version of xHarbour then with it's included C
compler (xCC), otherwise with your C compiler of choice.

> - Sorry - S&R?  Syntax and ??  Could you elucidate?

Sorry, "Search & Replace".

Ron

Ron,
Thanks for that.  I'm going to be travelling for a couple of ws but it
looks like I'll have to have a 'play' with the xHarbour I downloaded some
time ago when I get back.  Thanks for the help...

--
Rob Grattan
R&D Software Pty. Ltd.

Hi there,

just to complete :

Beware of .obj Files > 64 KB : split .prg into multiple parts
Beware of too many .obj files  : merge .prg together (yes I know the last
line , life sometimes is not easy)
as you did : change private to locals
Update to blinker 7, this cured many mysterious errors and the mouse crash
on 5.3 under xp

and if anything fails : just include some statements like nDummy  :=  0,
cDummy := "zuzuzu"

it sounds like voodoo, but it helps

Greetings
tom




"Mel Smith" <medsyntel@aol.comnocrud> schrieb im Newsbeitrag
news:20041119132743.06280.00000527@mb-m26.aol.com...
> Dear Friends,
>
>    Enviro:  a protected mode app (with Packcode, Packdata, and Compress in
the
> .lnk file) using Clipper 5.2e and Blinker 5.1
>
>    After an hour of testing/fixing I have resolved a weird GPF.
>
>    I was making extensive changes in a tbrowse module (shopbrow.prg), and
after
> quite a few changes, compiled the app (approx 76 modules).
>
>    The compile was successful.
>
>    When I started up the app, I got an immediate GPF !! (I didn't even get
into
> the main menu !)
>
>    After a bunch of work (i.e., checking the new code against a back up
copy,
> and gradually building the new module again, I finally got to an innocuous
> assignment statement that cause the crash:
>
>       dSAVCHKDTE := CHEKDATE      // dSAVCHKDTE is a private vrbl
>
>    Removing this statement resolved the GPF but caused me terrible
confusion.
>
>    After much more work I made the dSAVCHKDTE a LOCAL vrbl and this
removed the
> GPF.
>
>    Can anybody explain this GPF cause & cure to me ???
>
>    BTW, I went over the whole module again, and 'LOCALized' all the vrbls
that
> I possibly could, and I'm back-in-action again after a 'terrifying'
morning (I
> 'terrify' easily these days :))  )
>
> TIA,
>
> -Mel Smith
>
>
>