1. Silly Scribble Program
Ad asked for conversion of David's scribble program
to "dos", using any library of choice...
below is my answer to that 'challenge'...
it reads as easy (if not easier) as the original
winsnorz program, and doesn't require the 80 or more
megs of winsnorz *bloat*... :)
side note: since the latest update of TrueEU affects
confined mouse work, it's best to use that latest
version of TruMouse/TrueEU with this program...
I'm not sure how an older version of TrueEU would
behave while running this scribble program...
enjoy! --Hawke'
---------------------begin TruScribble.ex
include trumouse.e
object mouse
integer draw, x, y, oldx, oldy, event
procedure drawline(integer sx,integer sy,integer ex,integer ey)
mouse_pointer(MOUSEOFF) --hide the mouse
true_line(sx,sy,ex,ey,TrueWhite) --draw a line
mouse_pointer(MOUSEON) --show the mouse
end procedure
x = 0 y = 0
oldx = 0 oldy = 0
draw = FALSE
mouse_cursor("cursor.tga")
mouse_init()
mouse_events(MOVE+LEFT_DOWN+LEFT_UP)
--set up a 'window'
mouse_pointer(MOUSEOFF)
mouse_confine({100,100},{250,250})
true_box(99,99,251,251,TrueBlue,FALSE)
mouse_pointer(MOUSEON)
while 1 do
mouse = -1
while atom(mouse) do
mouse = get_mouse()
if get_key()!=-1 then GoodBye() end if
end while
event = mouse[1]
if event = MOVE then
if draw then
x = mouse[2] y = mouse[3]
drawline(oldx,oldy,x,y)
oldx = x oldy = y
end if
elsif event = LEFT_DOWN then
oldx = mouse[2] oldy = mouse[3]
draw = TRUE
elsif event = LEFT_UP then
x = mouse[2] y = mouse[3]
draw = FALSE
end if
end while
---------------------end TruScribble.ex
2. Re: Silly Scribble Program
I just got around to looking at Hawke's version of TruScribble, and noticed
that he made many of the mistakes that I documented in my prior post.
Specifically:
- not using and_bits to test the mouse state
- making the tests mutually exclusive
As a result, the code ignores certain mouse events (such as MOVE+LEFT_UP)
and continues to draw lines after the mouse has been released. Of course, he
could always rewrite TruMouse to return the mouse events as *seperate*
events, like I did in the WinLib library I wrote for my version of Scribble.
Here's the code with the errors:
-- BEGIN SNIPPET OF HAWKE'S CODE --
if event = MOVE then
if draw then
x = mouse[2] y = mouse[3]
drawline(oldx,oldy,x,y)
oldx = x oldy = y
end if
elsif event = LEFT_DOWN then
oldx = mouse[2] oldy = mouse[3]
draw = TRUE
elsif event = LEFT_UP then
x = mouse[2] y = mouse[3]
draw = FALSE
end if
-- END SNIPPET OF HAWKE'S CODE --
The corrected version might look something like:
-- BEGIN FIXED SNIPPET OF HAWKE'S CODE --
if and_bits( event, MOVE ) then
if draw then
x = mouse[2] y = mouse[3]
drawline(oldx,oldy,x,y)
oldx = x oldy = y
end if
end if
if and_bits( event, LEFT_DOWN ) then
oldx = mouse[2] oldy = mouse[3]
draw = TRUE
end if
if and_bits( event = LEFT_UP ) then
x = mouse[2] y = mouse[3]
drawline(oldx,oldy,x,y)
draw = FALSE
end if
-- END FIXED SNIPPET OF HAWKE'S CODE --
-- David Cuny
3. Re: Silly Scribble Program
"Cuny, David" wrote:
> I just got around to looking at Hawke's version of TruScribble, and noticed
> that he made many of the mistakes that I documented in my prior post.
*blush*
and what's _really_ funny is that i -did- read that particular
post, and (really!) meant to incorporate those mistake solutions...
personally... i think doing the following is 'cleaner' than
using and_bits... i never found reading code using those functions
to be 'easy to digest'...
if event = MOVE then
blahblahblah
elsif event = LEFT_UP or --is there a left_up at all?
event = MOVE+LEFT_UP then
blahblahblah
elsif event = LEFT_DOWN or --is there a left_down at all?
event = MOVE+LEFT_DOWN then
blahblahblah
end if
i dunno, just seems easier to read to me...
you can see exactly what the coder is 'thinking'...
either solution of course is fine, as long as
one of them is actually *implemented* :)
>Of course, he could always rewrite TruMouse to return the
>mouse events as *seperate* events, like I did in the WinLib
>library I wrote for my version of Scribble.
i don't remember the contents of that post... however,
i'm assuming that your suggestion to change TruMouse
to return individual events would mean a sequence returned
from get_mouse that was always the same length that had a
location for each event, or, naturally, an atom -1 if nuffin
happened as defined by mouse_events.
like:
constant
MOVE = 1,
LEFT_UP = 2,
LEFT_DOWN = 3,
MIDDLE_UP = 4,
MIDDLE_DOWN= 5,
RIGHT_UP = 6,
RIGHT_DOWN = 7,
MOUSE_X = 8,
MOUSE_Y = 9
object mouse
mouse_events({MOVE,LEFT_DOWN,RIGHT_DOWN}) --note adjusted syntax
if mouse then became {1,0,1,0,0,0,0,251,109}
you would have a MOVE+LEFT_DOWN situation at 251,109?
you would ask questions like:
if mouse[LEFT_DOWN] then --do some action
elsif mouse[RIGHT_DOWN] then --context menu?
elsif mouse[MOVE] then --some sort of 'mouseover' action?
and you wouldn't have to worry about missing any
events, wouldn't need to use and_bits, and wouldn't
have real complex if/elsif/endif statments???
Is this what you meant?
if so, it is easily implementable (i say that -now- ;)
and i would be happy to do so if the consensus of users
of TruMouse desired that... i might do it anyway, cuz
i think i like it better myself anyway... it does make
'clean' reading code, i think...
thanks for noticing that tho... mistakes like that are
so easy to make, and so hard to spot/debug... mebbe I
won't make it again now :)
onwards--Hawke'
4. Re: Silly Scribble Program
Hawke' wrote:
> however, i'm assuming that your suggestion to
> change TruMouse to return individual events would
> mean a sequence returned ...
That's essentially the same as and_bits, with more overhead.
Look at the way that you wrote your code; I think that's how people would
prefer the mouse to behave - complex mouse events are broken down into
*seperate* events. So MOVE by itself returns:
first poll: { MOVE, x, y }
But LEFT_DOWN+RIGHT_UP, requires two calls to get_mouse() to get all the
information:
{ LEFT_DOWN, x, y }
{ RIGHT_UP, x, y }
With a mouse event such as MOVE+LEFT_UP+RIGHT_DOWN, the MOVE is redundant,
and can be simplified to two seperate polls (XXX_UP events are returned
first):
{ LEFT_UP, x, y }
{ RIGHT_DOWN, x, y }
There's one more feature: the mouse code keeps track of the state of the
mouse, and the state of the user's knowledge. So if a LEFT_UP occurs while
the user is busy painting the screen, the get_mouse() routine would realize
the states are out of sync, and return:
{ LEFT_UP, x, y }
on the next poll. That way, the user doesn't have to worry about missing
mouse events, or have to maintain a complex state machine for the mouse. It
seems to work just fine in Dos32Lib.
-- David Cuny
