cursor position

[Andreas Fischer]

hi,

i would like to find out if the cursor is in the command line or not; but surprisingly both CURSOR and LINENUM statement end with rc=0 and return line 1; i would have expected something like rc=4 and/or line 0 (as column is being set).

is there any way to find out if the cursor is in command line or in line 1?

regards,
andi

[Binyamin Dissen]

Show your code.

On Thu, 2 May 2019 12:23:13 +0200 Andreas Fischer
<andreas...@generali.com> wrote:

:>hi,

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Andreas Fischer]

well i just tested it as simple as:

label9 = 'ZCSR'                                                      
"(line88) = linenum .&label9."                                      
say 'rc: ' !! rc !! ', line88: ' !!  line88                          
                                                                     
                                                                   
   "(line2, col99) = cursor"                                        
say 'rc: ' !! rc !! ', line: ' !!  line2 !! ', col: ' !! col99      

at least in the description of the CURSOR command, it describes that behaviour: If the CURSOR location is ... command line: the LINE number is ... first display line

hence the question, maybe there's another command that let's me know?

regards,
andi


ispf-...@nd.edu schrieb am 02.05.2019 12:41:49:

> Von: "Binyamin Dissen" <bdi...@dissensoftware.com>

> --
> You received this message because you are subscribed to the Google
> Groups "ISPF discussion list" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ispf-l-list...@nd.edu.
> To post to this group, send email to ispf-...@nd.edu.

[Jeremy Nicoll]

On Thu, 2 May 2019, at 11:49, Andreas Fischer wrote:
> well i just tested it as simple as:
>
> label9 = 'ZCSR'
> "(line88) = linenum .&label9."

Why is there a trailing dot in that? I used to use

"(var) = linenum .ZCSR"

--
Jeremy Nicoll - my opinions are my own.

[Binyamin Dissen]

You have to do this in the panel code.

Edit macros work on the edit area.

On Thu, 2 May 2019 12:49:06 +0200 Andreas Fischer
<andreas...@generali.com> wrote:

:>well i just tested it as simple as:

[Andreas Fischer]

i always end variables with trailing dots.

regards,
andi


ispf-...@nd.edu schrieb am 02.05.2019 12:55:39:

> Von: "Jeremy Nicoll" <jn.ls....@letterboxes.org>

> An: ispf-...@nd.edu
> Datum: 02.05.2019 12:56
> Betreff: Re: [ISPF-L] cursor position
> Gesendet von: ispf-...@nd.edu

>

[Jeremy Nicoll]

On Thu, 2 May 2019, at 12:01, Andreas Fischer wrote:
> i always end variables with trailing dots.

You're conflating a CLIST language thing where a variable
name like &THING would sometimes need a trailling dot,
and errors could be avoided by always including them,
and an internal ispf level of support for that if I remember
correctly.

But your code is in rexx so really I'd expect you to write

label9 = 'ZCSR'
"(line88) = linenum" label9

(so rexx would evaluate the last of those as

(line88) = linenum .ZCSR

then pass that to the editor.

I queried it because I wondered if the trailing dot might
cause the line being queried not to be the ZCSR one.

[Paul Gilmartin]

On 2019-05-02, at 06:55:36, Jeremy Nicoll wrote:

> On Thu, 2 May 2019, at 12:01, Andreas Fischer wrote:
>> i always end variables with trailing dots.
>

... maximizing the possibility of confusion with Rexx compound symbols.

> You're conflating a CLIST language thing where a variable
> name like &THING would sometimes need a trailling dot,
> and errors could be avoided by always including them,
> and an internal ispf level of support for that if I remember
> correctly.
>
> But your code is in rexx so really I'd expect you to write
>
> label9 = 'ZCSR'
> "(line88) = linenum" label9
>
> (so rexx would evaluate the last of those as
>
> (line88) = linenum .ZCSR

> ^
> ^^^
Where does that dot come from?

> then pass that to the editor.
>
> I queried it because I wondered if the trailing dot might
> cause the line being queried not to be the ZCSR one.

-- gil

[Paul Gilmartin]

Did I reply from the wrong account? I didn't get an echo.
Retrying:

On 2019-05-02, at 06:55:36, Jeremy Nicoll wrote:

> On Thu, 2 May 2019, at 12:01, Andreas Fischer wrote:
>> i always end variables with trailing dots.
>

... maximizing the possibility of confusion with Rexx compound symbols.

> You're conflating a CLIST language thing where a variable
> name like &THING would sometimes need a trailling dot,
> and errors could be avoided by always including them,
> and an internal ispf level of support for that if I remember
> correctly.
>
> But your code is in rexx so really I'd expect you to write
>
> label9 = 'ZCSR'
> "(line88) = linenum" label9
>
> (so rexx would evaluate the last of those as
>
> (line88) = linenum .ZCSR

> ^
> ^^^
Where does that dot come from?

> then pass that to the editor.
>
> I queried it because I wondered if the trailing dot might
> cause the line being queried not to be the ZCSR one.

-- gil

[Jeremy Nicoll]

On Thu, 2 May 2019, at 14:50, Paul Gilmartin wrote:
> On 2019-05-02, at 06:55:36, Jeremy Nicoll wrote:

> ... maximizing the possibility of confusion with Rexx compound symbols.

I very nearly made the same point.

> > But your code is in rexx so really I'd expect you to write
> >
> > label9 = 'ZCSR'
> > "(line88) = linenum" label9
> >
> > (so rexx would evaluate the last of those as
> >
> > (line88) = linenum .ZCSR
> > ^
> > ^^^
> Where does that dot come from?

From me being an idiot. When I typed

label9 = 'ZCSR'

I originally typed

label9 = '.ZCSR'

then decided to take the dot out of there and put
it into the following line, and then didn't do that.

[Marvin Knight]

Edit is treating the cursor as being in the first line of the data displayed when a command is typed and the cursor is not moved out of the command line.   If you have to know if the cursor is in the command line versus the first line of data displayed you can use the variables zscreeni and zscreenc.    Variable zscreenc will show the cursor position in the logical screen.  Variable zscreeni will show the actual screen data.  You can use POS('Command ===>',zscreeni) to determine the starting position of the command line.  Likewise you can look for 'Scroll ===>' for the end position.   If zscreenc falls in that range then you are in the command line.  Keep in mind you can type in a command and then place the cursor in a protected field such as in the asterisks of the Top of Data line.   For example:

 /*REXX*/                                                    
 Address ISREDIT "MACRO"                                    
 Address ISPEXEC "VGET (ZSCREENC ZSCREENI)"                  
 SAY "CSR IS "ZSCREENC                                      
 xx = POS("Command ===>",ZSCREENI)                          
 yy = POS("Scroll ===>",ZSCREENI)                            
 /* note that zscreenc starts at 0 */                        
 xx = xx+12   /* adjust to actual start of input */          
 yy = yy-3    /* adjust to actual end of input area */      
 SAY xx yy                                                  
 EXIT                                                                                    




Marvin Knight

[Paul Gilmartin]

Administrivia:
I thought I subscribed to this list from my @AIM.com account.
Lately (for a test) I registered a GMail account. I did not
change my ISPF-L subscription parameters. Now ISPF-L messages
are appearing in my GMail inbox (only). Unwittingly, I replied
to one from GMail. Not seeing an echo in several minutes, I
replied again, from @AIM.com. Promptly, I received an echo
*to*my*GMail*inbox*!

WTF!?

(Local part and human name are the same for both accounts.
But, still ...)

On 2019-05-02, at 08:35:13, Jeremy Nicoll wrote:

> On Thu, 2 May 2019, at 14:50, Paul Gilmartin wrote:
>> On 2019-05-02, at 06:55:36, Jeremy Nicoll wrote:
>
>> ... maximizing the possibility of confusion with Rexx compound symbols.
>
> I very nearly made the same point.
>

One might naively misuse compound stems as if they were simple
variables. For example:
Pi. = 3.14; say Pi.
prints:
3.14

(There's probably a performance cost.)

Does CLIST follow the same lexical separation conventions as
JCL and Assembler, possibly requiring the dot?

It's dismaying that ISPF Services don't support Rexx compound
symbols, but instead the absurd MULTX mode. Why would any
Rexx programmer want to use that?

-- gil

[Andreas Fischer]

well thanks, that sounds like a promising hint! and now when you mention it, i think you've mentioned it once and i forgot about it, sorry for that.

regards,
andi


ispf-...@nd.edu schrieb am 02.05.2019 19:27:52:

> Von: "Marvin Knight" <kni...@us.ibm.com>

> An: ispf-...@nd.edu
> Datum: 02.05.2019 19:28
> Betreff: Re: [ISPF-L] cursor position
> Gesendet von: ispf-...@nd.edu

>

> hi,
>
> i would like to find out if the cursor is in the command line or
> not; but surprisingly both CURSOR and LINENUM statement end with
> rc=0 and return line 1; i would have expected something like rc=4
> and/or line 0 (as column is being set).
>
> is there any way to find out if the cursor is in command line or in line 1?
>
> regards,
> andi
> --
> You received this message because you are subscribed to the Google
> Groups "ISPF discussion list" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ispf-l-list...@nd.edu.
> To post to this group, send email to ispf-...@nd.edu.
>

[Andreas Fischer]

actually i never wrote CLISTs. can't tell you where i got it from, parmlib? ISPF? TWS? it's so long ago that i don't remember, and 'm simply used to it. sorry when it's confusing for you.

once talking about it, does it make a difference other than visibility when coding as you suggested, for example in terms of performace?

regards,
andi

ispf-...@nd.edu schrieb am 02.05.2019 14:55:36:

> Von: "Jeremy Nicoll" <jn.ls....@letterboxes.org>
> An: ispf-...@nd.edu
> Datum: 02.05.2019 14:55
> Betreff: Re: [ISPF-L] cursor position
> Gesendet von: ispf-...@nd.edu

>

[Jeremy Nicoll]

On Thu, 2 May 2019, at 20:59, Andreas Fischer wrote:
> actually i never wrote CLISTs. can't tell you where i got it from,
> parmlib? ISPF? TWS? it's so long ago that i don't remember, and 'm
> simply used to it. sorry when it's confusing for you.

It didn't confuse me.

> once talking about it, does it make a difference other than visibility
> when coding as you suggested, for example in terms of performace?

I doubt it, but whereas (as I vaguely remember) parts of ispf implicitly
understand "&thing" as a variable, I think that support dates a long
way back.

I'm a little surprised that it works with rexx variables too.

I think the most important reason not to use "&thing[.]" in rexx is that
outwith ispf it definitely will not work.

That is, when you use

label9 = 'ZCSR'
"(line88) = linenum .&label9."

ispf has somehow to understand that "&label9." means a
reference to a rexx variable named "label9" (ie without the "&").
OK, we know ispf can do that. But when someone does

label9 = 'ZCSR'
"(line88) = linenum ." || label9

or

label9 = '.ZCSR'
"(line88) = linenum" label9

rexx builds the expected 'pure' edit command (without unresolved
variables in it) and passes it to edit. If you had occasion to trace
execution of that you'd see the value of 'label9' being placed in the
command before it's passed to edit, whereas in what you've used
you'll only see the variable's name.

If you write an application in rexx you need to be clear whether rexx
or some other part of a system interprets the command string.

[Dave Salt]

If memory serves you need to check the column number rather than line number. If the column is zero it means the cursor isn't in the data area. Most likely it's on the command line, but it could also be in a line command area (or even below the data, but that's unlikely). In my experience, just knowing the cursor is or isn't in the data is usually enough.

Hope that helps,

Dave Salt

Sent from my Samsung Galaxy smartphone.