Putting multi-choice to the user ...

[vodkasoda]

The program I am working on is Text only,

It uses basic Input & Alert lines to request information from the user.

I want to add a new question and an Alert box seemed like the ideal solution, but it seems to only support 3 possible choices, when I need 4 ... is there a simple command I can use (MENU ?) which allows me to ask the user "Which of these do you want to do ?" ?

Is so, is there a link to an example of how to use that command, please ?!?

[lp]

http://gfa.atari-users.net/stg/gfabasic.htm#ALERT

If you need 4 options you have to do something else, or make the alerts messy. Like so:
|option #1|option #2|more...| if they click more... |option #3|option #4|
Not very elegant, but gets it done.

Or you can design your own dialog box with a resource editor and have as many options as you like.

[vodkasoda]

I am trying to cut down on user input, lp, so I don't want to use the "more..." option.

I did look at the "Menu" command in the manual but it's like reading Chinese !!!

Can you please expand / explain your comment "design your own dialog box with a resource editor" ? I am not a Basic expert by any means and struggle with most of this program as it is !!! If you could maybe show me a small example I could work on it to expand it, I wouldn't expect you to write all the code for me, but something I could expand upon would be really helpful ... Thanks

[simonsunnyboy]

If you are not restricted to clean GEM calls, I have a this old but nice POPUP menu source. It opens a popup menu at the current mouse coordinates but that can be changed.

t$ is the title and i$ the item list with items in a "A|B|C|D|E" fashion.
fontnr selects font size and abst is a small gap between heading and list or something. You can experiment with the parameters.

Code: Select all

FUNCTION popup(t$,i$,fontnr&,abst&)
  LOCAL n&,i&,i1&,x&,y&,b&,h&,k&,x1&,y1&,a$,n1&,xm&,ym&,th&,blin&
  '
  SELECT fontnr&
  CASE 0
    th&=6
    blin&=4
  CASE 1
    th&=8
    blin&=6
  CASE 2
    th&=16
    blin&=13
  ENDSELECT
  DEFTEXT 1,0,0,blin&
  ADD th&,abst&
  abst&=(abst&+1) DIV 2
  '
  FOR i&=1 TO LEN(i$)
    IF MID$(i$,i&,1)="|"
      INC n&
    ENDIF
  NEXT i&
  '
  DIM p$(n&)
  '
  FOR i&=0 TO n&
    i1&=INSTR(i$,"|",1)
    IF i1&<>0
      p$(i&)=LEFT$(i$,i1&-1)
    ELSE
      p$(i&)=i$
    ENDIF
    i$=RIGHT$(i$,LEN(i$)-i1&)
  NEXT i&
  '
  b&=LEN(t$)
  FOR i&=0 TO n&
    b&=MAX(b&,LEN(p$(i&)))
  NEXT i&
  IF fontnr&>0
    MUL b&,8
  ELSE
    MUL b&,6
  ENDIF
  ADD b&,12
  h&=th&*(n&+2)+13
  '
  MOUSE x&,y&,k&
  '
  x&=((MAX(x&-b& DIV 2,2)+6) AND &HFFF8)-6
  y&=MAX(y&-h& DIV 2,0)
  x1&=x&+b&-1
  WHILE x1&>319
    SUB x1&,8
    SUB x&,8
  WEND
  y1&=y&+h&-1
  IF y1&>199
    y1&=199
    y&=200-h&
  ENDIF
  '
  GET x&,y&,x1&,y1&,a$
  DEFFILL 1,0
  BOUNDARY 1
  PBOX x&,y&,x1&,y1&
  BOX x&+2,y&+2,x1&-2,y&+5+th&
  BOX x&+2,y&+7+th&,x1&-2,y1&-2
  '
  IF fontnr&=0
    TEXT (x&+x1&-LEN(t$)*6) DIV 2,y&+4+blin&+abst&,t$
  ELSE
    TEXT (x&+x1&-LEN(t$)*8) DIV 2,y&+4+blin&+abst&,t$
  ENDIF
  i&=y&+th&+9+blin&+abst&
  FOR i1&=0 TO n&
    TEXT x&+6,i&,p$(i1&)
    ADD i&,th&
  NEXT i1&
  '
  SHOWM
  n1&=-1
  DO
    MOUSE xm&,ym&,k&
    EXIT IF k&=1
    IF xm&>x&+2 AND xm&<x1&-2 AND ym&>y&+th&+6 AND ym&<y1&-3 ! Mauszeiger innerhalb
      ym&=ym&-y&-9-th&
      n&=ym& DIV th&
      IF n&<>n1&
        HIDEM
        VSYNC
        inv_eintrag(n&)
        IF n1&<>-1
          inv_eintrag(n1&) ! alten Eintrag deselektieren
        ENDIF
        SHOWM
        n1&=n&
      ENDIF
    ELSE
      deselect:
      IF n1&<>-1
        inv_eintrag(n1&) ! alten Eintrag deselektieren
        SHOWM
        n1&=-1
      ENDIF
    ENDIF
  LOOP
  ERASE p$()
  '
  PUT x&,y&,a$
  RETURN n1&
ENDFUNC
'
> PROCEDURE inv_eintrag(n&)
  GRAPHMODE 3
  DEFFILL 1,2,8
  BOUNDARY 0
  PBOX x&+4,y&+9+SUCC(n&)*th&,x&+b&-5,y&+8+ADD(n&,2)*th&
  GRAPHMODE 1
RETURN

[vodkasoda]

Thank you Simon, I will take a look ... I swear this program will be the death of me

[Mikefulton]

Why do retro-programming if you're just gonna make a plain text-based program? Why not do a real GEM program?

[jruark56]

MikeFulton,

I am not answering for the OP, but when I am learning a new system i lke to start with simple stuff and graduate to more complex. My first stab at programming on the ST via emulation was a simple text based program with input via keyboard. No GEM, no windows, no alert boxes. Just simple text.

Could be a valid approach.

[christos]

Why do retro-programming if you're just gonna make a plain text-based program? Why not do a real GEM program?

Not speaking for the OP either, but I found bitplanes easier to understand than GEM and I don't understand bitplanes. Like the OP, I used alert boxes but luckily I only needed three choices . Anyway, I am sure it's not as bad as the ARGV protocol

[Mikefulton]

MikeFulton,

I am not answering for the OP, but when I am learning a new system i lke to start with simple stuff and graduate to more complex. My first stab at programming on the ST via emulation was a simple text based program with input via keyboard. No GEM, no windows, no alert boxes. Just simple text.

Could be a valid approach.

Well, I wouldn't exactly say it's an invalid approach, but perhaps an outdated one.

In 1985, when the ST first came out, most of the people programming it hadn't done much, if anything, with MSDOS or UNIX systems, or other more sophisticated systems. They were generally more familiar with the previous generation of 8-bit machines, which didn't really have operating systems as such. Generally, the older 8-bit machines had a relatively simple ROM kernel that provided I/O functions and some basic utility functions for things like setting up a display screen. As a result, when you jumped into the ST and started poking around, the most familiar things you'd see would be the BIOS and GEMDOS functions for doing basic I/O stuff. So it made sense that the first programs you'd write would be relatively simple things that used those functions.

But now? Even if you're new to the ST, I'm not sure that makes a lot of sense. Especially if you have any sort of programming experience with any modern systems.

Turn things on their head... if you were sitting down to learn how to program Windows, would you start out by playing with BIOS text output functions? It's hard to imagine someone taking such an approach.

GEM is really not very complex, as GUI environments go. The hardest thing about it is the fact that you don't have application frameworks to manage the low-level aspects of the event handling process, as you would with Windows or other modern systems. But if that's your ultimate target anyway, you might as well starting aiming at it right from the start.

That's my 2 cents worth.

[Mikefulton]

Why do retro-programming if you're just gonna make a plain text-based program? Why not do a real GEM program?

Not speaking for the OP either, but I found bitplanes easier to understand than GEM and I don't understand bitplanes. Like the OP, I used alert boxes but luckily I only needed three choices . Anyway, I am sure it's not as bad as the ARGV protocol

Bitplanes aren't that hard... suppose you have a 16-color mode. That's 4 bit planes. Basically you get 2^n colors where 'n' is how many bit planes.

For each block of 16 pixels in width on a given scan line, the layout of screen memory is one 16-bit word per bit plane. Let's walk through the process of extracting the individual pixel values with a bit of pseudo code.

Code: Select all

First, set your "result" to zero.

For bit = 15 to 0 step -1

for bitplane = 0 to n step 1

rotate result 1 bit left

grab current bit from current bitplane and put it into bit 0 of result.

next bitplane

// Now your result will contain the pixel value which represents the hardware color register used by the video shifter to display that particular pixel.

next bit

// Now you can repeat the process for the next block of 16-pixels.



That could easily sound pretty confusing, but it's one of those things that's actually not that difficult once you have the proper "aha!" moment.