cursor position in field
Started by Gary Wilhelm, Oct 30 2002 04:55 PM
17 replies to this topic
#1
Posted 30 October 2002 - 04:55 PM
Is there any way from PROIV to set the cursor position to the end of the current text. I have a comments screen function that I would like to start each entry with the date and time. That part works fine, but the text is highlighted in GUI mode and cursor is at the beginning of the text in Green Screen mode. To get to the end I either have to arrow over in GUI mode or F10, then arrow over in Green Screen mode. It would be nice to be able to just F5 then start typing.
Thanx in advance,
Gary
Thanx in advance,
Gary
#2
Posted 30 October 2002 - 09:00 PM
Never used it, but I recalled reading simething vaguely like that....is this it?
@EMODE
Purpose When @EMODE is disabled (default), fields are automatically displayed in Add
mode. When it is enabled, the next field only is set to be in Edit mode.
Syntax @EMODE
Remarks This option can be called from Logic Before on the field to be edited or Logic After on
the previous field.
An @EMODE setting is in operation for one field only.
From Logic guide, around page 200
@EMODE
Purpose When @EMODE is disabled (default), fields are automatically displayed in Add
mode. When it is enabled, the next field only is set to be in Edit mode.
Syntax @EMODE
Remarks This option can be called from Logic Before on the field to be edited or Logic After on
the previous field.
An @EMODE setting is in operation for one field only.
From Logic guide, around page 200
#4
Posted 30 October 2002 - 09:35 PM
Never used it myself - so it's probably little help.
I just whacked this into a Bef field logic:
|001 IF @MODE = 'C' THEN
|002 ENABLE(@EMODE);
However, result was just as if I had ENTERed to the field and hit F10 - curs position was at the beginning of the field (however, it is in edit more).
Hopefully someone else has the appropriate command, or a definite 'no you can't do it'
I just whacked this into a Bef field logic:
|001 IF @MODE = 'C' THEN
|002 ENABLE(@EMODE);
However, result was just as if I had ENTERed to the field and hit F10 - curs position was at the beginning of the field (however, it is in edit more).
Hopefully someone else has the appropriate command, or a definite 'no you can't do it'
#5
Posted 31 October 2002 - 11:21 AM
As Rick says, ENABLE(@EMODE) should help.
I vaguely recall from green-screen days (I haven't done any UI work for years, ugh, those users, Sooo difficult..) that there were a couple of system variables that might be relevant.
I think these were @OFFSET and @XOFSET (sic). I can't remember what the difference is. However, as a GUESS, you might need to set something like:
@XOFSET = LEN($TheData)
..before processing the field.
Afraid I don't know if such things work with GUI either.
Maybe some use?
Richard
I vaguely recall from green-screen days (I haven't done any UI work for years, ugh, those users, Sooo difficult..) that there were a couple of system variables that might be relevant.
I think these were @OFFSET and @XOFSET (sic). I can't remember what the difference is. However, as a GUESS, you might need to set something like:
@XOFSET = LEN($TheData)
..before processing the field.
Afraid I don't know if such things work with GUI either.
Maybe some use?
Richard
Nothing's as simple as you think
#7
Posted 31 October 2002 - 02:06 PM
IF @MODE = 'C' THEN
ENABLE(@EMODE)
@XOFSET = LEN(RICK_VAR1) + 1;
Works in Green only, under V4.6 Rev 2.1.3 on HP-UX.
I couldn't see what @OFFSET did(?)
How do you and Richard find out these things? Memory, due to previous positions, or are you digging them out of somewhere? :-)
ENABLE(@EMODE)
@XOFSET = LEN(RICK_VAR1) + 1;
Works in Green only, under V4.6 Rev 2.1.3 on HP-UX.
I couldn't see what @OFFSET did(?)
How do you and Richard find out these things? Memory, due to previous positions, or are you digging them out of somewhere? :-)
#8
Posted 31 October 2002 - 02:15 PM
Hi Rick,
The @XOFSET variable is documented in the manual.
Rob D.
The @XOFSET variable is documented in the manual.
Rob D.
#11
Posted 31 October 2002 - 03:36 PM
if @EMODE causes change mode for the next field, why would you have an IF statement that checks if you are already in change mode..
IF @MODE = 'C' THEN
ENABLE(@EMODE)
@XOFSET = LEN(RICK_VAR1) + 1;
my code looks like this:
IF @MODE = 'A' THEN
ENABLE(@EMODE)
@XOFSET = LEN(MY_VAR) + 1;
unfortunately, now my screen is in an infinite loop and will not exit. '/' causes a jump to the next field now instead of cancelling out of the screen. And '.' causes a new line.
Help
Thanx,
Gary
IF @MODE = 'C' THEN
ENABLE(@EMODE)
@XOFSET = LEN(RICK_VAR1) + 1;
my code looks like this:
IF @MODE = 'A' THEN
ENABLE(@EMODE)
@XOFSET = LEN(MY_VAR) + 1;
unfortunately, now my screen is in an infinite loop and will not exit. '/' causes a jump to the next field now instead of cancelling out of the screen. And '.' causes a new line.
Help
Thanx,
Gary
#12
Posted 31 October 2002 - 04:12 PM
I must re-iterate that I have never used this before - I merely quickly inserted the code into an existing function purely to test a theory that I believed I had seen in the manual somewhere in the hopes that it would be of assistance - and maybe I'd learn something new too...
Nevertheless, in the context of the function I happened to choose (a Customer Maintenance function), and the field that I happened to choose (Customer Name) - the value of the Customer Name would ALAYS be {blank} in Add Mode - whereas, in Change Mode it would have a value. Being unfamiliar with the real-world use of this little switch, I used it in a manner which seemed logical to me. If in the context in which you are using it, your field has a value already, when in Add mode - then your code is logical.
I am puzzled by your results using '/' and '.' - logic would say to me, that if one is editting a field then / means / (as opposed to F11/ESC) and . means . (as opposed to F3/EOD).
Eg: Name: Rick Young_ <---- _ indicates cursor
If I type / and hit Enter, I now have
Name: Rick Young/ and I am now in the next field.
If I actually hit F11(escape), I now return to the first char position of the field, and remain in Edit Mode. If I now type /-enter, I now have a '/' in the first char position of the field. If I hit F11, I remain in the field, but am no longer in Edit mode. Now if I hit either F11 or /-enter, I return to first field.
If I hit F3(EOD), I arrive in my next input field.
Even altering my logic to simply omit @MODE checking, and I now try in Add Mode - the results are exactly the same. I can therefore only conclude, that you have other logic/field jumps/file return fields or something causing your issue.
If you throw a .prx up, I may have time later today or tonight to take a peek - or perhaps someone more skillfull than I will do so.
Nevertheless, in the context of the function I happened to choose (a Customer Maintenance function), and the field that I happened to choose (Customer Name) - the value of the Customer Name would ALAYS be {blank} in Add Mode - whereas, in Change Mode it would have a value. Being unfamiliar with the real-world use of this little switch, I used it in a manner which seemed logical to me. If in the context in which you are using it, your field has a value already, when in Add mode - then your code is logical.
I am puzzled by your results using '/' and '.' - logic would say to me, that if one is editting a field then / means / (as opposed to F11/ESC) and . means . (as opposed to F3/EOD).
Eg: Name: Rick Young_ <---- _ indicates cursor
If I type / and hit Enter, I now have
Name: Rick Young/ and I am now in the next field.
If I actually hit F11(escape), I now return to the first char position of the field, and remain in Edit Mode. If I now type /-enter, I now have a '/' in the first char position of the field. If I hit F11, I remain in the field, but am no longer in Edit mode. Now if I hit either F11 or /-enter, I return to first field.
If I hit F3(EOD), I arrive in my next input field.
Even altering my logic to simply omit @MODE checking, and I now try in Add Mode - the results are exactly the same. I can therefore only conclude, that you have other logic/field jumps/file return fields or something causing your issue.
If you throw a .prx up, I may have time later today or tonight to take a peek - or perhaps someone more skillfull than I will do so.
#13
Posted 31 October 2002 - 07:20 PM
Gary,
Don't confuse 'edit mode' - which applies to individual fields with 'change mode' - which applies to the whole logical screen.
Once you are in 'edit mode' for a field, the '/' and '.' characters no longer have any special meaning.
In fact '/' and '.' are just hangovers from the days when ProIV had no function-key support and they only work when they are the sole input and the field is NOT in edit mode (they don't even work if you key a trailing space after them).
Like Rick, I think your loop problem is probably caused by some other coding in your function.
Are you trying this out on green-screen or GUI?
Don't confuse 'edit mode' - which applies to individual fields with 'change mode' - which applies to the whole logical screen.
Once you are in 'edit mode' for a field, the '/' and '.' characters no longer have any special meaning.
In fact '/' and '.' are just hangovers from the days when ProIV had no function-key support and they only work when they are the sole input and the field is NOT in edit mode (they don't even work if you key a trailing space after them).
Like Rick, I think your loop problem is probably caused by some other coding in your function.
Are you trying this out on green-screen or GUI?
Nothing's as simple as you think
#14
Posted 31 October 2002 - 08:29 PM
Since $#@EMODE has no affect in GUI, I was in green screen mode. Sorry about the use of '/'. The employees here use those commands regularly, as you said, left over from before F keys. I am slowly trying to move all workstations to CPU's. This code isn't important enough to spend any real time on, and telling everyone here that '/' won't work in this case will probably cause more probs than it's worth. So I have just added to date/time and told them to go to edit mode manually with F10 to arrow to the last character.
Thanx for all you help anyway. I learned some things about @EMODE and @XOFSET.
Gary
Thanx for all you help anyway. I learned some things about @EMODE and @XOFSET.
Gary
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users