$if 0 旼컴컴컴컴컴컴컴컴컴컴컴컴캠 PowerBASIC v3.20 旼캑 DASoft 픔컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴� � 쳐컴컴컴컴컴컴컴컴컴컴컴컴캘 Copyright 1995 � DATE: 1995-10-01 픔� � � FILE NAME RODENTS .TXT � by 突袴袴袴袴袴袴袴羔 � � � � � Don Schullian, Jr. � � � 突袴袴袴袴袴袴袴袴袴袴袴袴暠 � � � A license is hereby granted to the holder to use this source code in � � � any program, commercial or otherwise, without receiving the express � � � permission of the copyright holder and without paying any royalties, � � � as long as this code is not distributed in any compilable format. � � � IE: source code files, PowerBASIC Unit files, and printed listings � � 突佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � � .................................... � 突袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� $endif "Rodentcia Tecknikus" seems to have infected almost every corner of the soft- ware market today whether it is needed, efficient, or not! To that end I must speak, for just a moment. The mouse is, in reality, a great pointing and selecting device. It does have limitations and any attempt to exceed those limitations puts an unnecessary burden on the tool. Also one has to take into account the tool's purpose in life and not use the it where it is not efficient. The mouse is restricted to moving a pointer around the screen, keeping track of where it is, and reporting on the status of any key or keys. A key can be "up", "down" or "clicked" ( was down is now up ). Each key has a number: 旼컴컴컴컫컴컴컴컴쩡컴컴컴커 � #1 � #3 � #2 � � � � � \ � � / 쳐컴컴컴좔컴컴컴컨컴컴컴캑 fig: #7342 � � Rodentcia Tecknikus Tributtonous Some mice have 2 keys and some have 3. If the mouse has only 2 buttons it can simulate a 3 button mouse if the user presses/releases the 2 buttons simultaneous but it is a human impossibility to "beat the machine" and get the buttons down or up together fast enough to get the desired results. Also, the "double-click" is not a feature of the mouse and must be programmed by pausing the program after the first "click" then checking to see if a second "click" happened within both the allotted time and area of the screen. In short, try to keep things down to 2 buttons and one click as much as possible and your programs will be shorter and easier to manage. Before the mouse is turned on (made visible) you have to initiate the mouse to make sure you're actually infested or not! Once the little guy is visible you can turn him on and off at will BUT.... for very time you turn him off you have to turn him on again before he's visible. In other words 3 "offs" need 3 "ons" and NOWHERE is there a function that supports the number of "offs" in the system so I've done it manually and that leads us to the conditional off function. You can tell DOS to turn the rat off if it is or goes inside a "box". Great idea but..... 1) it doesn't work all the time due to interrupt time! ie: you update the screen before the mouse checks if it is in the box. 2) you have NO WAY of knowing if the mouse was turned off or not! ie: how many "ons" do you need now? 旼컴� � HINT 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � MouseON and MouseOFF keep an internal record of how many OFF's there � � are so MouseONnow can issue enough ON's to get the cursor visible. � � If you have a routine that calls MouseON and MouseOFF with no chance � � of another routine coming in between the two then the fastest and � � tightest code is: � � asm mov ax,&h02 ; mouse off � � asm int &h33 � � ' code goes here � � asm mov ax,&h01 ; mouse off � � asm int &h33 � � in Basic: � � REG 1, 2 � � CALL INTERRUPT &h33 � � ' code goes here � � REG 1, 1 � � CALL INTERRUPT &h33 � � � � There is a conditional mouse OFF that turns the mouse off � � a) if it is inside the box you will be updating � � b) if the mouse moves inside the box � � BUT.................. � � a) you don't know and can't find out if the mouse was, in fact, � � turned off and if the conditional OFF is nested with other OFF/ON � � combos you could very easily get the mouse back on before it was � � time. � � b) if the screen under the mouse is updated before the mouse � � interrupt catches the fact that the mouse has moved into the box � � then the screen is left in an ugly state! � � HENCE................ � � It is best, especially with today's super quick computers, to simply � � issue an OFF/ON and let the rodent flicker a bit. � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Just to make things worse there are a whole flock of different drivers out there! If you finally find a function that does what you want it to do you have to check to make sure that the mouse driver that has been loaded into the system supports the function. This, basically, negates generic use of these third party functions, so just forget them! Does it seem that I'm down on the mouse?! Well, not really. Like I said at the beginning: "It's got it's place." The trick is to use it correctly and wisely and not attempt to overwork it. After all, it's only a mouse! The most useless place I've ever seen a mouse is in a word processor! What typist in their right mind wants to remove her/his hands from the home keys in the middle of a document? Ditto for data input. When and are so handy, why grope for a mouse to move to the next field?.... Now... on to the good part......... We've got the mouse running around, playing hide and seek and clicking at us all the while. How do we put this to use? Not too tough, once you've thought about it. Each time the mouse clicks we have a look at where it's at, test to see if it's location means anything to the routine then take action. Simple enough until you start getting boxes popping up "over" other boxes, etc. Now what do you do? The screen is, after all, only 2 dimensional! An area of the screen we will call an EVENT Each event will have one, or more, ITEMs inside it Event and item corners will be stored in 2 dimensional arrays These arrays will be fed into fEventOpenG? or fEventOpenT? GOTO EVENTS.TXT