Mouse

2006-11-02
2013-04-04
  • Back in the good old days :-) we didn't have a mouse, so there was no need for a mouse command in the simple basic interpreters back then. Should there be any kind of mouse commands now?

    One command could be like the input command, only for mouse clicks. Wait for a mouse-click in the graphic window, and then insert the x and y coordinates into some variables. That would make it possible to make a program asking "Click three times with the mouse" and then draw lines between the points, calculate the length of each line and so on.

    Does this sound like a good solution, or should the mouse be dropped or handled in some other way? (Keep in mind that it is BASIC and for kids, so event based mouse handling is not a solution)

    Sorry for trying to make more work for you drblast ;-)

     
    • Bill Russell
      Bill Russell
      2006-11-02

      Actually I think that's a great idea, and a mouse event really wouldn't have to be super complicated.  Just like there is a "key$" function to capture a key, I think the same could be done with the mouse.  The "mouse$" function could return one of the following responses:

      "{}"       This would mean no event
      "{SLEFT}"   This would mean single left click
      "{DLEFT}"   This would mean double left click
      "{SRIGHT}"  This would mean single right
      "{DRIGHT}"  Double right
      "{MOVE}"    This would mean the mouse has moved

      Two other values would have to be added in addition to mouse$: mousex, mousey

      so you could have some code like the following:

      lastx=mousex
      lasty=mousey

      loop:
        if mouse$="{}" then goto loop
        if mouse$="{DRIGHT}" then end
        if mouse$="{MOVE}" then newx=mousex:newy=mousey
        if mouse$="{SLEFT}" then line lastx, lasty, newx, newy:lastx=newx:lasty=newy
        goto loop

       
    • drblast
      drblast
      2006-11-02

      I don't think this would be too complicated to implement.  I'm thinking for simplicity sake, that the mouse command would look like this:

      MOUSE argument

      where "argument" would specify either position, left button, or right button.

      So, MOUSE 0 would return the position of the mouse, MOUSE 1 left button state, etc.

      The problem with this is that a number of people have requested a context sensitive menu for the output windows with options for taking screenshots and clearing the screen, and a MOUSE command would conflict with that.

      I'm going to have to think about this one.  Any other suggestions are welcome.

       
      • Bill Russell
        Bill Russell
        2006-11-03

        The mouse function should only work if the graphics window has focus, otherwise the kids program would have to deal with extra mouse information that would complicate the code.  Perhaps there could be a focus key, such as <F10> to switch between windows.  You may need to add a command to give the graphics window focus for the mouse too, because for most apps the user may not want to deal with the narrowed focus for the mouse.  Do you want to add a point variable which can hold x,y locations?  This might make future graphics work easier.

         
    • I think it would be better to put screenshots and clearing of the screen in a menu (maybe the edit menu or a new menu). Imagine a proud eight year old who has made a program with some mouse interaction inside the graphic view, and then want to let the five years old sibling try it, only to see that the kid hits the right mousebutton followed by a left click which suddenly wipes out all the nice graphic. TuxPaint (a paint program for young kids) even has an option to let the left and right mouse key work the same to accomodate young children.

      I think there should be a command that works like input (waits for a click), so you could do something like:

      mouseclick
      x1 = mouseclick_x
      y1 = mouseclick_y
      mouseclick
      x2 = mouseclick_x
      y2 = mouseclick_y
      line x1,y1,x2,y2

      In many cases this is what you want, and then you don't have to think about loops.

      A command like Bill Russell suggest is more powerfull but also more difficult. You don't only need to master loops, but also think about how to avoid infinite looping. You could of course add two commands ;-)

       
      • Bill Russell
        Bill Russell
        2006-11-03

        You offer a good alternative.  IMHO, it seems like our kids will also need to capture a keyboard event (for lack of a better word) at the same time though.  The reason is that in a program using this command, the kid will most likely want a way to end (like pressing <ESC> or <Q>).  In terms of it being more complicated, I'm not as concerned since capturing mouse commands is likely to be something taught after these other concepts anyway.  Also, even when I was younger, I had to do something similar in GWBasic with a command called INKEY$.  I don't remember being too intimidated by that.

        As a side note, I've noticed the "line" command is naturally coming into play when we discuss the mouse.  At the risk of starting a new thread, that would also be a good addition.

        Take care,
        Bill

         
        • drblast
          drblast
          2006-11-03

          I've just added a line command, so that will be in the next release.

           
    • I must admit I don't know how fast the kids will grasp the stuff. When I got my first computer and started programming Basic I was about 13 years old (and that was about 24 years ago, so I don't really remember what was hard ;-). Today I think they'll start soon after they've learned to read and write, say between 6 and 9 years old. My son is 4 years, so he'll not be able to start yet, but I know it would be much easier to explain the input-style than the key-style command. BTW, the key command is a one key buffer, so if the mouse command should work identical, it would store the last mouse click until the mouse command is called.

      The most flexible solution would of course be to have both an input style and a key style mouse command :-)

      I guess part of the question is how long they will use Basic-256 before going to some other language. At least for the moment, there are no file commands or other kinds of storage like cookies. There are no support for sending stuff to the printer. The key command is limited to keys that return an ascii-value, so no f-keys, arrow-keys and so on. It is possible to create quite cool games using fastgraphics, but when they reach such an advanced level, it will probably be easier to make it in some other language. Personally I don't think Basic-256 should try to cater to advanced needs. It won't be able to compete in that arena, and might loose on the easy to learn aspect.

      The hard part is of course to draw the line between what it should have, and what it shouldn't, and in the end drblast must make that decision.

      BTW, it is possible to get out of a loop with an input style mouse command as well, since the key command use a buffer:

      print "Click the mouse to start drawing."
      mouseclick
      x1 = mouseclick_x
      y1 = mouseclick_y
      print "Press a key before your last mouse click. Continue clicking the mouse to draw."
      loop:
      mouseclick
      x2 = mouseclick_x
      y2 = mouseclick_y
      line x1,y1,x2,y2
      x1 = x2
      y1 = y2
      if key = 0 then goto loop

      But then the user has to push a key before doing the last mouse click which isn't quite natural.

       
      • SuperNatendo
        SuperNatendo
        2007-03-21

        It is possible to store f-keys and arrow keys to a variable using the key command, here is an example:

        rem This program waits for the user to press a key on the keyboard.  When a key is pressed it displays the numerical value that BASIC-256 assigns to that key.  This is useul for programs that use the keyboard for user input to move graphics on the screen.

        label:
        x = key
        if x = 0 then goto label
        cls
        print x
        goto label

         
    • Bill Russell
      Bill Russell
      2006-11-03

      On a separate thread, Tore (torebj) brought up an interesting question regarding at what point should we transition kids from BASIC-256 to a more advanced language.  I think this starts with a look at what got us interested.  So, here are my thoughts, and I'd be very interested in anyone else's thoughts/advice on the matter.

      I remember the first program I ever tried was when I was in 2nd grade on an Apple II computer.  It was with turtle logo.  I was fascinated with it, but was not allowed to use the computer freely until 6th grade.  During my 6th grade year, we learned very basic structured concepts that we built upon.  We met once a week for an hour.  From what I remember (granted this is a long time ago), here is the basic path we took:

      We developed sub routines (which were called To <Label> <parameters>):

      To Triangle :size
      To Square :size
      To Hexagon :size
      To Circle :size
      To Spiral :size
      To House :size
      To Star :size
      To Shape :size :sides  

      We learned basic drawing commands, and then followed it with "To" commands.  The "To" command was essentially a sub routine.  Then we learned loops, but then those concepts were reinforced over and over.  I guess I would like to be able to do the same with my kids.  Each week the teacher would show us a picture, and we had to write a program to create the picture.  That was the thrill of learning.  My son is 7 and is ready to learn, but he needs to see pictures to stay interested. I would like to have a kid's programming language, quite possibly KidBasic, be interesting enough to focus one school-year on teaching basic concepts.  As a side note, I'd be happy to work along side of a couple of people to come up with a kids curriculum along these lines.

       
    • I'm interested in Montessori pedagogy, so I tend to think in three year cycles :-) The children go in the same class for three years, though the class of course change since the oldest children moves up to the next class, and younger kids start. The children to some degree decide themself what to work on, so the entire class isn't doing the same thing and not everybody are using the same amount of time on everything. They work individually or in small groups, and the tasks are made so they can see themself if they do it correctly (because it can't be done any other way, or because they can look at a/the correct answer when they are done).

      I assume that not everybody will love programming and look for new languages to master, but basic programming skills will be usefull for everybody since simple macro programming in different programs can save them tons of work.

      I doubt that children schools will have time to teach more than one language, and assuming not every child will love it, I don't think they should. I think that 6-9 is a nice age to learn basic programming, but the language should be strong enough to use for math for 9-12 years old as well (I think kids should learn to do math without calculator/computer, and if/when they use one, at least they should program it themself ;-).

      I agree that the tasks should be very visual. Basic drawing would be a good task, moving on to simple animation and simple games. Math is also nice. Needless to say, I'll join in on making the curriculum, and I know the local Montessori school will at least have a look at what we do and give some feedback.

       
  • Jim Reneau
    Jim Reneau
    2010-01-27

    Mouse functionality was added recently.  MOUSEB, MOUSEX, MOUSEY will track the mouse as it moves across the graphics window and CLICKB, CLICKX, CLICKY, and CLICKCLEAR will record the last clicked location on the screen ( and reset it).  It has been added to the documentation and sample programs have been added.

    Jim