Preprossesor xcommand problem

[James Bott]

This code:

Code: Select all  Expand view  RUN

   @ 1,1 xbutton

generates a "syntax error" message when used with the following preprocessor #xcommand:

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> PROMPT ] <cPrompt> ;
      => ;
         [ <oBtn> := ] TxButton():New(<cPrompt>)

However, this preprocessor #xcommand works without error:

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> ] ;
      => ;
         [ <oBtn> := ] TxButton():New()

This code works without error with both #xcommands above:

Code: Select all  Expand view  RUN

   @ 1,1, xbutton oBtn

So it seems that oBtn is not optional in the first #xcommand. Is there a way to change the first #xcommand so that oBtn is optional?

Regards,
James

[quique]

James, sorry if my english is bad and I don't understand fine your problem, or I don't explainme fine.

The first definition forces to write <cPrompt>

@ 1,1 xbutton "hola"

if you don't want <cPrompt> be obligatory, you can try with

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ [ <oBtn> PROMPT ] <cPrompt> ] ;
      => ;
         [ <oBtn> := ] TxButton():New(<cPrompt>)

[James Bott]

Quique,

Actually, cPrompt is optional with my first example (and also with yours).

I am trying to figure out if it is possible to make oBtn optional also.

James

[quique]

James, with

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> PROMPT ] <cPrompt> ;
      => ;
         [ <oBtn> := ] TxButton():New(<cPrompt>)


<cPrompt> isn't optional, for you do it optional you need to use [], you can do it

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> PROMPT ] [<cPrompt>] ;
      => ;
         [ <oBtn> := ] TxButton():New(<cPrompt>)


then you can write

@ 1,1 xButton
@ 1,1 xButton "Hola"
@ 1,1 xButton oBot prompt "Hola"
and
@ 1,1 xButton oBot prompt
@ 1,1 xButton "hola" oBot prompt

look the 2 last they are because [ <oBtn> PROMPT ] and [<cPrompt>] are independent

so

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ [ <oBtn> PROMPT ] <cPrompt> ] ;
      => ;
         [ <oBtn> := ] TxButton():New(<cPrompt>)


it indicates <cPrompt> is optiona and if <cPrompt> is indicated optionally it's possible to write <oBtn> PROMPT

[quique]

One forgot to me

This code works without error with both #xcommands above:

Code: Select all  Expand view  RUN

   @ 1,1, xbutton oBtn

So it seems that oBtn is not optional in the first #xcommand. Is there a way to change the first #xcommand so that oBtn is optional?

I think you think oBtn indicate the variable where the object will be saved with your first sample of #xcommand

It's wrong, in this sample oBot is the variable that indicate <cPrompt>

oBtn := "Hola"
@ 1,1, xbutton oBtn

[xProgrammer]

Hi James

You could use two #commands to overcome the problem

Regards

Doug

[nageswaragunupudi]

The following code is properly getting complied and linked for me:

Code: Select all  Expand view  RUN

#include 'fivewin.ch'

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> PROMPT ] <cPrompt>  => ;
   [ <oBtn> := ] TXButton():new(  <nRow>, <nCol>, <cPrompt> )

function main()

   local oBtn, oWnd

   @ 10,10 XBUTTON  'XButton'
   @ 20,10 XBUTTON oBtn PROMPT 'Test'

return nil


CLASS TXButton

ENDCLASS


PPO output (Relevant Part only)

Code: Select all  Expand view  RUN

function main()

   local oBtn, oWnd

   TXButton():new( 10, 10, "XButton" )
   oBtn := TXButton():new( 20, 10, "Test" )

return nil



Probably the problem is because all the <var>s are not used in the translate in the first sample posted

[James Bott]

NageswaraRao,

>The following code is properly getting complied and linked for me:

But you cannot do this:

@ 1,10 xbutton prompt "XButton"

This whole thing started when I tried to do:

@ 1,1 button msgInfo( cWhatever )

I try to use this periodically when I am debugging, but it always gives me a syntax error, then it takes me awhile to figure out why since I forget since I did it last. I was just trying to figure out how to prevent the syntax error. Also, if you use an object name then you have to define it as a local, so when you are done debugging you have to remember to remove the local declaration also when you remove the debugging code.

So the simple fix, I thought, was to modify the include file.

I note that you don't have to assign object names to GETs when you redefine them, so I thought there must be a way to make buttons work the same.

James

[nageswaragunupudi]

Mr James,

>
But you cannot do this:

@ 1,10 xbutton prompt "XButton"
>
Yes. You can not write like this, but you can write :

@ 1, 10 XBUTTON "XButton"
This usage is consistant with the usual FWH syntax.

But if you want to write either
1) @ 1,10 XBUTTON oBtn PROMPT 'XButton'
or
2) @ 1,10 XBUTTON PROMPT "XButton"

then please change the xcommand as :

Code: Select all  Expand view  RUN

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> ] PROMPT  <cPrompt>  => ;
   [ <oBtn> := ] TXButton():new(  <nRow>, <nCol>, <cPrompt> )


With both the commands I have given, we can write
@ 1,10 XBUTTON oBtn PROMPT 'Test'

With my first version of command, we can write
@ 1,10 XBUTTON 'Test' // consistant with FWin usage
but not
@ 1,10 XBUTTON PROMPT 'Test' // different from FWin usage.
// Even FWin commands fail if we write like this
With the second command I have just given in this posting, we can wiite
@ 1,10 XBUTTON PROMPT 'Test' // the way you wanted to write
// but not the standard way we write
// Fivewin buttons
and we can NOT write
@ 1,10 XBUTTON 'Test' // Normal FWin syntax fails
-------------
You have both versions of the command now.
But I still recommend you the command that is consistant with the FWin syntax. Anyway that is your choice.

[James Bott]

NageswaraRao,

>You have both versions of the command now.

Yes, but I still do not have a solution to my original problem. I cannot write:

@ 1,1, button action msgInfo( cWhatever )

Even though I can write:

redefine get var cVar

You mention consistant FW syntax, but with a button you must include the object name, but with a GET you don't have to.

James

[James Bott]

NageswaraRao,

I must add that this is very confusing:

You can write:

@ 1,10 XBUTTON 'Test' // consistant with FWin usage

but not

@ 1,10 XBUTTON PROMPT 'Test' // different from FWin usage.

But you can also write:

@ 1,10 xbutton oBtn prompt 'Test'

And you cannot write:

@ 1,10 xbutton oBtn 'Test'

This kind of thing had given me fits before.

So, it may be consistant that FW has always worked this way, but the usage of certain clauses is not consistant--sometimes you need it, sometimes it is optional, sometimes you can't use it.

It would be logical that the object name should be optional since you don't always need it. It would also be logical that if you are going to specify a PROMPT value then you must specify the PROMPT clause. The prompt clause and the value together should be optional.

The way it is now the object name and the prompt clause are related. This is not logical.

Perhaps this kind of thing cannot be achived with the preprocessor--I don't know.

James

[James Bott]

Quique,

>look the 2 last they are because [ <oBtn> PROMPT ] and [<cPrompt>] are independent

OK, this seems to be the issue. As I said in my previous message, logically oBtn should be independent from PROMPT and cPrompt. oBnt should be optional, and PROMPT should be required if cPrompt is specified.

Then these would be valid syntax:

@ 1,1 button prompt "button"
@ 1,1 button oBtn
@ 1,1 button oBtn prompt "button"

And these would be invalid:

@ 1,1 button "button"
@ 1,1 button oBtn "button"

OK, that is just considering the logic of the syntax. Of course, we have to consider legacy code, and we can't break it, so the best solution would if all of the above were valid syntax.

Actually, it must be even more complex since you cannot do:

@ 1,1 button action msgInfo()

And this does work:

@ 1,1 button oBtn action msgInfo()

So it seems that in order to use any clause (not just the PROMPT clause), you must specify the object name, oBtn.

James

[nageswaragunupudi]

Mr James

First I gave a command which is consistant with Fivewin syntax.
When you desired it differently, I gave a command which does what I understood your requirement to be, though not consistant with Fivewin syntax.

From your latest post I undersand that :

You like to have it differently from the present Fivewin syntax;
You want that object as well as prompt should be optional and if prompt is specified, PROMPT clause "must" be used.

In other words, you like the folowing three usages must be syntactically corect:
1. @ 1,10 XBUTTON oBtn PROMPT 'myprompt'
2. @ 1,10 XBUTTON PROMT 'myprompt' // PROMPT clause is needed
3. @ 1,10 XBUTTON // both obtn and prompt are ommitted.

If I understood you correctly, here is the solution:

Code: Select all  Expand view  RUN

#include 'fivewin.ch'

#xcommand @ <nRow>, <nCol> XBUTTON [ <oBtn> ] [PROMPT  <cPrompt>]  => ;
   [ <oBtn> := ] TXButton():new(  <nRow>, <nCol>, <cPrompt> )

function main()

   local oBtn, oWnd

   @ 10,10 XBUTTON  PROMPT 'XButton'
   @ 20,10 XBUTTON oBtn PROMPT 'Test'
   @ 30,10 XBUTTON

return nil

CLASS TXButton;ENDCLASS


PPO ( relevant part)

Code: Select all  Expand view  RUN

function main()

   local oBtn, oWnd

   TXButton():new( 10, 10, "XButton" )
   oBtn := TXButton():new( 20, 10, "Test" )
   TXButton():new( 30, 10, )

return nil


I drafted the command translate as per my understanding of what you desired. if it is something different, we can attempt a different translate.

I do not like to enter into a discussion whether the present Fivewin style is logical or not. I am used to writing my code the way Fivewin expects me to write and it does not really bother me. I took this as an opportunity to improve my skills of drafting command translates. Thanks for the opportunity.

[James Bott]

NageswaraRao,

>If I understood you correctly, here is the solution:

I found the same solution late last night.

>I do not like to enter into a discussion whether the present Fivewin style is logical or not.

I did not mean to imply that Fivewin's style was wrong. I was just trying to separate the logic from the current FW syntax so I could better understand the preprocessor and also why I couldn't write command syntax that seemed logical to me.

>I am used to writing my code the way Fivewin expects me to write and it does not really bother me.

The problem for me has been remembering the different syntaxes. The rules are not documented anywhere that I am aware of. I would have never guessed that the PROMPT clause was optional when you specified a prompt value, but only sometimes.

I have now come to these conclusions regarding rules for the use of the @ nRow, nCol button syntax:

1) If you wish to use any clause (including PROMPT), then you MUST also use the object name.

2) The PROMPT clause is optional UNLESS you use the object name, then it is required.

3) For all other clauses with an associated value, the clause is required. The PROMPT clause is the only exception and only when there is no object name specified.

Do I have this right?

I'll probably still forget this 6 months from now, so I am going to have to put this in my notes.

To repeat, my original problem is writing debugging code using a button. If I do:

@ 1,10 button oBtn action msgInfo()

Then I must also define the local oBtn, and I must remember to remove both when done debugging.

One solution might be to create a new #xcommand that handles this syntax:

@ 1,10 xbutton action msgInfo()

and preprocesses it using the proper syntax to the standard TButton class. Then I would not have to declare the local.

>I took this as an opportunity to improve my skills of drafting command translates.

That is why I started this thread. I know very little about the preprocessor commands and I would like to understand them better.

I was also hoping that the standard FW xcommand translate could be modified to handle both traditional FW syntax and my desired syntax, but it seems this is not possible.

It does seem that rules like this would have been simpler to remember:

1) The object name is optional
2) All clauses are optional.
3) If there is a clause value, the clause name is required.

I just noticed that other xcommands are different:

#xcommand @ <nRow>, <nCol> CHECKBOX [ <oCbx> VAR ] <lVar> ;
[ PROMPT <cCaption> ] ;

In this case it seems that the PROMPT command is always required when a prompt value is specified. So we really need different sets of rules for each command.

Thanks for your input, NageswaraRao.

Regards,
James

[quique]

James

Sorry, the english is some difficult for me, and I don't understand completely your posts, but I think the syntas of commands must be esay for how use it, not necessarily it must agree with the general rules. Why fivewin uses its syntax? Because it decided it to Antonio, it can be because therefore he liked or because he copied of the syntax xbase. Why dbase usus its syntax? Because it decided therefore it invented who it. But if you need other syntax you can use the preprocessor, for that is it.

What you need? At first you don't mention action sintax, for that we (at least I) think you use it clause like fivewin. How I understand, you can't do what you want, because the preprocessor doesn't know what do.

As you can distinguish what of these you want to use?

@ 1,1 xbutton "Hola"
@ 1,1 xbutton oBtn
@ 1,1 xbutton msgInfo( "hola" )

all have same syntax, one parameter after xbutton, then you need choice one option you can use, how you say, fivewin have tow knds to manage the command syntax, and can be more.

perhaps I do not like to use

@ 1,1 xbutton oBtn prompt "hola"

I like to use

@ 1,1 xbutton "Hola" object oBtn

or

@ 1,1 xButton msgInfo( "press" ) prompt "hola" object oBtn

the only rules that you must obey are preprocessor's rules, not fivewin's rules, not xbase's rules, it's recommendable to follow the rules general, but nonobligatory, and less if it is what your you need.

Then, that is what you need? you can write some examples of the command like you want they will be write and then we will be able to see as they are viable