Skip to main content

I need to display 3 controls on the same line, without any gaps between them:

   label with proportional font

   push-button

   label with proportional font

I want to do 3 consecutive displays and not have to use WIN$TEXTSIZE to compute control sizes.  (That's too slow over the internet, when you are doing this multiple times)

The text interface has the cursor concept and back-to-back strings display right after each other.  Even in thin client.  But display a label and the cursor does not update.   I have a sample program I put into labelposn.zip and attached (source and object - version 10.2.1) which illustrates cursor positioning and display of controls.  Basically, it does not work.

I need to display 3 controls on the same line, without any gaps between them:

   label with proportional font

   push-button

   label with proportional font

I want to do 3 consecutive displays and not have to use WIN$TEXTSIZE to compute control sizes.  (That's too slow over the internet, when you are doing this multiple times)

The text interface has the cursor concept and back-to-back strings display right after each other.  Even in thin client.  But display a label and the cursor does not update.   I have a sample program I put into labelposn.zip and attached (source and object - version 10.2.1) which illustrates cursor positioning and display of controls.  Basically, it does not work.

The cursor should be in the entry-field 

DISPLAY LABEL "Test 4, part 1:"
 UPON INIT-WIN-HANDLE COL 1 LINE 7.
DISPLAY PUSH-BUTTON "Fx1"
 UPON INIT-WIN-HANDLE col 12 line 7 size 2.
DISPLAY LABEL "Test 4, part 2"
 UPON INIT-WIN-HANDLE col 15 line 7.


The cursor should be in the entry-field 

DISPLAY LABEL "Test 4, part 1:"
 UPON INIT-WIN-HANDLE COL 1 LINE 7.
DISPLAY PUSH-BUTTON "Fx1"
 UPON INIT-WIN-HANDLE col 12 line 7 size 2.
DISPLAY LABEL "Test 4, part 2"
 UPON INIT-WIN-HANDLE col 15 line 7.

While it's true that the cursor keyword is only applicable to an entry field, the documentation uses that word to refer to the concept of a "next screen location".  That virtual position on the screen gets updated after one display so the next one appears at that location, when the display does not override with row/col keywords.

The use of " " is clever - but will it handle proportional font?  I'll have to try it and get back to you.


The cursor should be in the entry-field 

DISPLAY LABEL "Test 4, part 1:"
 UPON INIT-WIN-HANDLE COL 1 LINE 7.
DISPLAY PUSH-BUTTON "Fx1"
 UPON INIT-WIN-HANDLE col 12 line 7 size 2.
DISPLAY LABEL "Test 4, part 2"
 UPON INIT-WIN-HANDLE col 15 line 7.

As I feared, the places the label relative to the front of the preceding control (more accurately, probably relative to the last specified column) rather than relative to the END of the preceding control.   I used test strings of WWWWW and ||||| to test this.  I got overlap with W's and gaps with bars.  I've attached the updated program (labelposn2) and a screen capture.

I think it's interesting that when I test the same "display after last control" with text it works.  And when I do the same with gui, the 2nd label does appear slightly to the right of where the first field displayed.  So there is still a "current position" concept inside the thin client, it just appears to be computing incorrectly.  I could be wrong, but that's what it looks like.

Do you have a plan B?

 

 

 


As I feared, the places the label relative to the front of the preceding control (more accurately, probably relative to the last specified column) rather than relative to the END of the preceding control.   I used test strings of WWWWW and ||||| to test this.  I got overlap with W's and gaps with bars.  I've attached the updated program (labelposn2) and a screen capture.

I think it's interesting that when I test the same "display after last control" with text it works.  And when I do the same with gui, the 2nd label does appear slightly to the right of where the first field displayed.  So there is still a "current position" concept inside the thin client, it just appears to be computing incorrectly.  I could be wrong, but that's what it looks like.

Do you have a plan B?

 

 

 

I had hoped the using would help, but I had considered that it may not. I do not have a plan B. Perhaps someone else will present a solution

I had hoped the using would help, but I had considered that it may not. I do not have a plan B. Perhaps someone else will present a solution

Is it possible for development to change (fix?) the internal handling of the "current position" so that in gui mode, displaying a label changes the position to the appropriate location (ie WIN$TEXTSIZE pixels to the right of the starting point?)   And with a button, the appropriate size for the button specified?  It works in gui systems when using character mode.


Is it possible for development to change (fix?) the internal handling of the "current position" so that in gui mode, displaying a label changes the position to the appropriate location (ie WIN$TEXTSIZE pixels to the right of the starting point?)   And with a button, the appropriate size for the button specified?  It works in gui systems when using character mode.

Please contact Customer Care with this. They can submit this issue to Development. Thanks.