Some GENSCRNX guru around? 2

[TheSofty]

Hi all,

I'm trying to recover from a bad crash of my HD, but something is just not working anymore on an old app written in FPW26A that uses GENSCRNX, 3DCTRL and 3D drivers. To summarize:

in a screen I have some textbox with a When 'Expression' snippet with

IsAdding OR IsEditing

These are two logical vars created as .F. in the screen code at the beginning, so they should be available at any time. Before that, at the very beginning, I have:

*:SCXDRV5 3DCTRL
*:SCXDRV6 3D
*:BOX3D 2
*:ALL3D
*:IGNOREBRACES

In Config.FPW, among other things, is:

_GENSCRN="GENSCRNX.PRG"
_GENMENU="GENMENUX.PRG"
_SCXDRV5="3DCTRL"
_SCXDRV5="3D.PRG"
MVCOUNT=512

All these PRG/APP are in the folder wher FoxPro is.

Now, when I make some mods on the screen and try to compile the project, I get:

"Error: IsAdding OR IsEditing. Unrecognizable command verb.". The error line is:

FUNCTION click_adfc
IF when_adfd(m.objen_adff)
RETURN valid_adfe()
ELSE
IsAdding OR IsEditing <-------------------------
ENDIF

Apparently something isn't generated properly.

My code is always been there. What setting did I screw up?

Thanks

 

[DSummZZZ]

You're saying that line gets auto generated in that function from a when expression? Is it getting generated there instead of the associated @...GET or along with it?



-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TheSofty]

The @...GET are also generated, since I see them in another part of the .SPR.

 

[TheSofty]

The real code where this happens is this:

FUNCTION when_ct9u
PARAMETER llObjEnabled
IF !llobjEnabled
RETURN .f.
ELSE
IsEditing OR IsAdding <-------------------------
ENDIF

 

[DSummZZZ]

What do you mean by 'the real code'? Is that function also getting automatically generated?


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TheSofty]

I mean that it is the actual code generated. Before I had given what I recollected by memory.

The question is: what configuration piece in GENSCRNX/3DCTRL/3D is missing, since that exact code worked for five years untouched?

Thanks

 

[JRB-Bldr]

IsEditing OR IsAdding by itself is not an executable line of code. It would be like FALSE .OR. TRUE with no command making a conditional test for TRUE OR FALSE.

However if this is in a screen's When snippet, you need to have

RETURN IsEditing OR IsAdding

And you need to make sure that the snippet is checked as an Expression rather than as a Procedure.

Perhaps you need to modify your When expression to something like:
IF !llobjEnabled
RETURN .f.
ELSE
RETURN IsEditing OR IsAdding <----------
ENDIF

Which would Disable or Enable the GET field accordingly to the IsEditing and/or IsAdding variable values.

BTW - If this is your problem, it has nothing do to with GENSCRNX.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[TheSofty]

I completely agree with you: that line is the culprit. In fact, it's what the compilers chokes on. The problem is that I have that expression (ie: without RETURN) in the WHEN snippet of that textbox since the start, 5+ years. I never cared to see the code generated by GENSCRNX/3DCTRL/3D (it worked flawlessly), but I think it adds the RETURN. As I said, I wonder what is missing now. Stepping in GENSCRNX.PRG shows that it does its things, but apparently not correctly.

Thanks

 

[DSummZZZ]

It could be that genscrnx got cofused somehow, or the screen file is confusing it somehow. Maybe try removing the snippet, generating, and re-adding to the snippet.
I dunno, I'm stabbing in the dark here.
I know you said it's the same code, but obviously there's something goofy going on that's hard to pin down from afar.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[JRB-Bldr]

One possibility is that the snippet is now being seen as a PROCEDURE rather than as an EXPRESSION.

Open the screen and look at how the GET's WHEN snippet is marked.

If this were a PROCEDURE then it would definitely fail. But as an EXPRESSION, there is an implied RETURN prior to the expression and the code should work.

I have not personally had difficulty making GENSCRNX behave properly where this became a problem, but it could be a possibility.

If this were happening, one possible way around it would be to change the expression to a PROCEDURE and explicitly put in the appropriate code.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[TheSofty]

Dave, JRB-Bldr

thank you all for trying to help.

The first think I took care to control was indeed the 'Expression' radio button in the snippet, and it was there.

I'm at a loss. I think that Plan B is in order: the hell with the fancy graphics and GENSCRNX! I'll go back to the old GENSCRN to re-gain affordability, and then, in a week or so, I'll try to re-add the other stuff.

Only time will tell.

Thanks again for your time. A star for you.

Thesofty

 

[DSummZZZ]

Instead of abandoning the fancy graphics, why not go ahead and use the pretty screen? Just generate it and remove the offending line from the .SPR prior to compiling it.
You can always track down the funkiness later.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm