Locate:

[random1]

Does qb64 have a option similar to _Printstring (x-pixel,y-pixel) for Locate.
I often need to use something like "Input N$" but need to place it at a [x y]
position.  If not, maybe it could be added to the next release.

R1

[bplus]

I made my own graphics input that can do fonts:

Code: QB64: [Select]

1. Option _Explicit
2. _Title "fINPUT testing brief" 'B+ started 2020-06-29 cut stuff 2021-12-27
3.  
4. Const xmax = 1000, ymax = 500
5. Screen _NewImage(xmax, ymax, 32)
6. _Delay .25
7. _ScreenMove _Middle
8.  
9. Dim f36 As Long, myStr$
10. f36 = _LoadFont("Arial.ttf", 36) ' everyone has this right?
11. Color &HFFFFFF00, &HFF880000
12. While _KeyDown(27) = 0
13.     Cls
14.     myStr$ = fINPUT$(f36, &HFF9999FF, 200, 250, "Enter name: ")
15.     Print "fInput returned: "; myStr$
16.     Print "screen will clear in 3 secs..."
17.     _Delay 3
18. Wend
19.  
20. Function fINPUT$ (fh&, foreColor~&, x, y, prompt$)
21.     Dim oldFont&, oldBC~&, oldFC~&, olddisplay, screenshot&
22.     Dim done As _Byte, OK$, k$, t$
23.     oldFont& = _Font '_printwidth(s$, desth&)
24.     oldBC~& = _BackgroundColor
25.     oldFC~& = _DefaultColor
26.     olddisplay = _AutoDisplay
27.     screenshot& = _NewImage(_Width, _Height, 32)
28.     _PutImage , 0, screenshot&
29.     _Font fh& 'get measures
30.     Color foreColor~&, 0
31.  
32.     _PrintString (x, y), prompt$ + " {} "
33.     OK$ = "ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz"
34.     OK$ = OK$ + Chr$(8) + Chr$(27) + Chr$(13) + "1234567890!@#$%^&*()_-+={}[]|\:;'<,>.?/"
35.     Do
36.         _PutImage , screenshot&, 0
37.         k$ = InKey$
38.         If InStr(OK$, k$) Then
39.             If k$ = Chr$(8) Then
40.                 If t$ <> "" Then
41.                     If Len(t$) = 1 Then t$ = "" Else t$ = Left$(t$, Len(t$) - 1)
42.                 End If
43.             Else
44.                 If k$ = Chr$(13) Or k$ = Chr$(27) Then
45.                     If k$ = Chr$(27) Then t$ = ""
46.                     Exit Do
47.                 Else
48.                     t$ = t$ + k$
49.                 End If
50.             End If
51.             _PrintString (x, y), prompt$ + " {" + t$ + "}"
52.             k$ = ""
53.         End If
54.         _Limit 60
55.         _Display
56.     Loop Until done
57.     fINPUT$ = t$ 'return the sub's var$ with desired entered or escape string.
58.  
59.     'restore
60.     If olddisplay Then _AutoDisplay
61.     _FreeImage screenshot&
62.     Color oldFC~&, oldBC~&
63.     _Font oldFont&
64. End Function
65.  
66.  

Also have an Input box that doesn't mess up your screen and that you can drag around the screen.

[random1]

bplus

This is what I am using now.  I thought there might be a keyword i was missing.
Hitting the return key exits the loop so it works much like line input.  I would
like to see a keyword option like _Locatexy which would work like the code
below.

R1

syntax would look something like -> locatexy(10,10), input n$

Code: QB64: [Select]

1. KEYLIST$=".+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
2. KEY1$=""
3. DO
4. SLEEP
5. K$=RIGHT$(INKEY$,1)
6. IF INSTR(KEYLIST$,K$) < 1 THEN EXIT DO
7. KEY1$=KEY1$+K$
8. _PRINTSTRING (10,10), KEY1$
9. LOOP
10.  

[TempodiBasic]

K$=RIGHT$(INKEY$,1)
IF INSTR(KEYLIST$,K$) < 1 THEN EXIT DO

WOW
that is the first time that I see a code that shows why  returning TRUE (-1) from INSTR is useful when the searched string is void ("").

Thanks random1

PostScriptum 1: is it less complicated than the use of IMP?  Maybe it is.

PostScriptum 2: surely here you write

locatexy(10,10), input n$

  but you would type

Code: QB64: [Select]

1. locatexy(10,10): input n$
2.  

because locatexy moves the position of cursor, and it is for input and output.

[SMcNeill]

Am I missing something, or is this as simple as:


InputString 10, 10, "What is your name", user$
Print "Your name is "; user$

SUB InputString (x, y, prompt$, return$)
   LOCATE x, y
   INPUT prompt$, return$
END SUB

[random1]

SMcNeill

Locate y,x gives you row and column not the x,y pixel position.

R1

[random1]

TempodiBasic

It took me forever to get use to _printstring (x,y) as locate always used Locate y,x, LOL
Yes, I should have used Locatexy (10,10):


R1

[SMcNeill]

SMcNeill

Locate y,x gives you row and column not the x,y pixel position.

R1

Then just reverse them in your SUB:

InputString 10, 10, "What is your name", user$
Print "Your name is "; user$

SUB InputString (x, y, prompt$, return$)
   LOCATE y, x
   INPUT prompt$, return$
END SUB

[random1]

Locate y, x gives us the row and column of a fixed grid so to say. Lets say that I have
a input cell box that is not aligned with the grid.   In the old days we used locate and
print which was also tied to a grid, _printstring removed that limitation and we can
now print to any location.  All I am saying is that Locate could be updated to select
the x and y pixel location instead of the y,x grid. 

R1
     

[SMcNeill]

Locate y, x gives us the row and column of a fixed grid so to say. Lets say that I have
a input cell box that is not aligned with the grid.   In the old days we used locate and
print which was also tied to a grid, _printstring removed that limitation and we can
now print to any location.  All I am saying is that Locate could be updated to select
the x and y pixel location instead of the y,x grid. 

R1
   

That won't happen without breaking legacy code.  QB45 has locate work by character position; not pixel position.  If you absolutely must have an input that's pixel-precise, you'll want to write your own routine for that.  I've got a few on here for that purpose.  Terry Ritchie has a GLINPUT library (Graphic Line Input).  Several options already exist out there, if you don't want to roll your own.

Side note:  If you use non-monospaced fonts, LOCATE drops legacy support and offers pixel precision placement on the x-axis.  Y-axis is still by row, however.

[OldMoses]

I've occasionally thought that an "_INPUTSTRING(x,y), in$,etc." would be kinda nice, but after all is said and done, I really don't like INPUT to begin with. I use it for quickies and unsophisticated stuff, but I prefer properly constrained and conditioned input for important UI. I'm sure it's nice for freeing up clock cycles to the system and all, when it's waiting on us molasses slow humans, but we have _LIMIT for that.

I recently used an approach somewhat similar to the fINPUT$ function that Bplus posted. His is much nicer and more complete. Mine built an input string a character at a time from allowable possibilities. fINPUT$ has a similar algo at its core. Used in a display loop, the string it creates can be placed anywhere via _PRINTSTRING and doesn't have to interfere with other loop inputs, like mouse ops. It won't accept characters improper to the input sought, and can be dealt with appropriately as a string or VAL'd for numerical input.

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(400, 400, 32)
2. xp% = 0: yp% = 0
3. DO
4.     CLS
5.     x$ = INKEY$
6.     WHILE _MOUSEINPUT: WEND
7.     IF _MOUSEBUTTON(1) THEN
8.         xp% = _MOUSEX: yp% = _MOUSEY
9.     END IF
10.     IF x$ <> "" THEN
11.         IF x$ = CHR$(13) THEN
12.             EXIT DO
13.         ELSE
14.             Build_Str b$, "0123456789.", x$
15.         END IF
16.     END IF
17.     _PRINTSTRING (xp%, yp%), b$
18.     _LIMIT 30
19.     _DISPLAY
20. LOOP
21. CLS
22. PRINT "You entered "; b$; " @ ("; xp%; ","; yp%; ")"
23. END
24.  
25. SUB Build_Str (main AS STRING, allow AS STRING, kp AS STRING)
26.  
27.     'Build a string out of allowable characters(allow) received via keypress(kp), return in 'main'
28.     SELECT CASE kp '                                            keypress as case selection
29.         CASE IS = CHR$(8) '                                     if backspace pressed
30.             IF LEN(main) > 0 THEN '                             and main string exists
31.                 main = LEFT$(main, LEN(main) - 1) '             remove rightmost character
32.             END IF '
33.         CASE ELSE '                                             if anything other than backspace
34.             IF INSTR(allow, kp) <> 0 THEN '                     if an allowable character has been pressed
35.                 main = main + _TRIM$(kp) '                      add it to main string
36.             END IF '
37.     END SELECT '
38.     kp = "" '                                                   clear the input
39.  
40. END SUB 'Build_Str
41.  

INPUT is just a loop awaiting a keypress to respond with an appended echo, so I just take those reins and do it myself. It's certainly more work, but it's just one of those things you develop to your taste and put in an $INCLUDE library or a cut and paste template.

[bplus]

Yeah, the beauty of DIY is you can modify it to the particular needs of the app.

[OldMoses]

Just thinking out loud, but...

Since there seems to be a precedent set with WIDTH & _WIDTH

Would having a LOCATE & _LOCATE create too many development challenges and/or confusion?

[bplus]

How does that work when people choose the option not to use the _underlines?

[SMcNeill]

How does that work when people choose the option not to use the _underlines?

In this case, Width is a SUB and _WIDTH is a function.  The parser differentiates the two by usage.

LOCATE and _LOCATE, however, would both be Subs and wouldn't work.  Even bigger problem would be that the internals would need a complete overhaul...

For example, let's LOCATE 3 pixels right, 3 pixels down and PRINT "foo".

The way things are now, we increase ROW by one, so we can print in the proper spot below it on the next line.  Only problem here is we've offset 3 pixels below a normal row...

What should CSRLIN and POS print for us?  How do we track that 3 pixel offset?  With _FONT 8, width and height of a font is 8 pixels...   Normally we print at ROW 1, COLUMN 1 (0, 0 pixels), hit ENTER, and move down to ROW 2...

But here, we located to 3,3 before printing.

Does the next row start at 8 pixels like usual?  Do we go in and make CSRLIN and POS report SINGLE values?  We're at row 1.4, column 1.4? 

All these commands are interconnected and work off the premise of ROW and COLUMN coordinates.   Once LOCATE changes, all of their underlying structures change as well.

Now, somebody will ask, "WHY DO WE HAVE A _PRINTSTRING COMMAND THEN?"

The answer to that is, "It exists outside LOCATE, CSRLIN, POS, POINT, SCREEN, and all those other interconnected commands."

Try this:

LOCATE 10, 10
_PRINTSTRING (1, 1), "Test"
PRINT "Foo"

Where does that Foo print?  Down on line 2, below the Test from _PRINTSTRING?  Or is it in relationto that last LOCATE at 10, 10, and completely unaffected by that Test??

Our LOCATE coordinate system is integer-based, and dependent on _FONTHEIGHT and _FONTWIDTH.  To change it to pixel-based, you'd need to alter all the existing code to swap from grid-coordinates over to pixel-coordinates...

Anyone want to volunteer to do that?  All I can say is it won't be me.  I don't have the time to undertake such a massive alteration for something which I doubt I'd ever use at all.  ;)