#11000-#GEM Bug List #: 11020 S2/GEM Support 04-Sep-86 01:13:17 Fm: Tom Jeffries 73717,2261 To: SYSOP*Dave Groves 76703,4223 Here's a bug for which I still need a solution. GEM does not always seem to report the release of a mouse button. I've tried evnt_multi(), vq_mouse(), a routine that steals the mouse interrupt and checks the buttons before handing things back to GEM, and a few other things and in all instances the status returned is not always correct. It is correct if you move the mouse, which leads me to think that the mouse packet doesn't always get sent (which, of course, would not be a GEM bug). John Feagans at Atari said they were not aware of this problem; however, several other developers on the Atari BBS reported the same thing. It happens on the Desktop sometimes: you click on an option but nothing happens until you move the mouse. I hope someone has solved this one. #: 11023 S2/GEM Support 04-Sep-86 01:21:46 Fm: Tom Jeffries 73717,2261 To: SYSOP*Dave Groves 76703,4223 Evnt_timer() doesn't always happen. I've never tried to find out any details, but sometimes you just don't get a noticeable time delay when you call the function. #: 11041 S2/GEM Support 04-Sep-86 03:39:23 Fm: Corey Cole 76224,66 To: Tom Jeffries 73717,2261 We've run into several symptoms that appear to be manifestations of this (mouse state change not being reported back properly). In particular, we discovered that vq_mouse often reports an out-of- date error status, while evnt_multi and evnt_mkstate "go into the tank" for a noticeable time (approx. 1-2 seconds, perhaps a bit less) before returning correct status. This applies even when the "number of clicks" parameter is set to one (not looking for multiple clicks), and even if the mouse is instantly moved outside of the mouse click dither range. We reported the latter to DRI at their GEM seminar in April of 1985, but the problem still exists in version 1.2 of IBM PC GEM, as well as on the ST. -- Corey #: 11048 S2/GEM Support 04-Sep-86 10:37:13 Fm: Quack Computer Co.,NM 75426,3451 To: SYSOP*Dave Groves 76703,4223 A GEM bug : If a virtual floppy disk is installed after system start-up, the system bombs when required to do virtual disk swapping. Disk swapping works fine if the floppies are installed on start-up, though. #: 11053 S2/GEM Support 04-Sep-86 12:59:39 Fm: Dan Moore 74035,243 To: Tom Jeffries 73717,2261 I can confirm the mouse packet DOES get sent since I have played with the packet handler. I think the "missed" release is in GEM or the GEM packet handler. #: 11075 S2/GEM Support 04-Sep-86 23:06:47 Fm: Tom Jeffries 73717,2261 To: Dan Moore 74035,243 Very interesting. That means it would be worth writing my own interrupt routine and avoiding GEM. I've been holding off because I thought it might be in the hardware. Thanks! Tom Jeffries #: 11041 S2/GEM Support 04-Sep-86 03:39:23 Fm: Corey Cole 76224,66 To: Tom Jeffries 73717,2261 We've run into several symptoms that appear to be manifestations of this (mouse state change not being reported back properly). In particular, we discovered that vq_mouse often reports an out-of- date error status, while evnt_multi and evnt_mkstate "go into the tank" for a noticeable time (approx. 1-2 seconds, perhaps a bit less) before returning correct status. This applies even when the "number of clicks" parameter is set to one (not looking for multiple clicks), and even if the mouse is instantly moved outside of the mouse click dither range. We reported the latter to DRI at their GEM seminar in April of 1985, but the problem still exists in version 1.2 of IBM PC GEM, as well as on the ST. -- Corey #: 11073 S2/GEM Support 04-Sep-86 23:04:18 Fm: Tom Jeffries 73717,2261 To: Corey Cole 76224,66 Thanks, Corey. If you ever find a solution please let me know. I have a situation where I'd like some text to keep scrolling as long as the mouse button is held down in a certain location, but because of this bug it will sometimes keep scrolling after the button is released. Not good. Tom #: 11068 S2/GEM Support 04-Sep-86 22:36:34 Fm: Christopher F. Chabris 73277,305 To: SYSOP*Dave Groves 76703,4223 Just to put in my two cents worth: I suggested to Tim Oren a few days ago that the compendium that we are now compiling include all types of ST bugs, not just GEM ones. Accordingly, I suggest that the GEMDOS bugs that have been responsibly documented by Atari in the GEMDOS spec in DL7 be included here for the benefit of non-registered developers who do not have access to the manual. Each function given there has a list of zero or more known bugs which should be put in the list.-- Chris Chabris #: 11061 S2/GEM Support 04-Sep-86 20:34:09 Fm: Mark McCulley 72337,3500 To: Tim Oren I seem to remember some discussion here a while back about nested event_multi() problems and problems that can occur if the message buffer is not cleared. I don't remember if the two problems were related. Anybody remember the essence of that discussion? What happens if you just ignore messages (assuming the event_multi is NOT waiting on a message)? #: 11063 S2/GEM Support 04-Sep-86 21:29:34 Fm: Tim Oren 76703,202 To: CHUCK WALBOURN 73537,527 Chuck, first of all I don't have anything to do with RCS any more, having left DRI over a year ago. As to Pascal, version 2.0 which will EVENTUALLY be released by DRI/Atari does have hooks for Pascal, Fortran, and BASIC. I put them in before I left. Unknown trees are mainly used when a resource is opened and there isn't any definition file - then you retype them to whatever you want. Or, you can make a tree an UNKNOWN if you want to leave a reminder that it is odd in some way, and shouldn't normally be altered. - Tim #: 11105 S2/GEM Support 05-Sep-86 20:21:54 Fm: Anker Berg-Sonne 72337,3211 To: SYSOP*Dave Groves 76703,4223 I have been battling a really weird problem in EAS and VDI for quite a while. First the scenario. I'm writing an editor that used GEM windows to look into several disk files and use v_text() to write the text. Everything works just fine until I resize the window manually with the mouse. If I make the window smaller on both axes text doesn't appear in the box until I do another resize that makes one of the axes larger! Clearly there's a solution to the problem, since 1stword can handle that case. I have tried all kinds of tricks, but to no avail. The problem is easy enough to reproduce with apskel.c by inserting a call to v_text in the routine that does the painting. I'm at my wit's end HHHHEEEEELLLLLLPPPPP! #: 11106 S2/GEM Support 05-Sep-86 20:24:35 Fm: Anker Berg-Sonne 72337,3211 To: Anker Berg-Sonne 72337,3211 Of course I meant v_gtext() where I wrote v_text(). #: 11113 S2/GEM Support 05-Sep-86 23:34:54 Fm: Alan Page 72227,3507 To: Anker Berg-Sonne 72337,3211 GEM doesn't seem to send redraw messages if you shrink a window, just if you enlarge it. My solution was to check the size change when I get the WM_SIZED message, and if neither axis is being increased then send myself a redraw message as in Tim Oren's self_redraw code in the GEM tutorials. #: 11111 S2/GEM Support 05-Sep-86 22:47:28 Fm: NEIL R LINCOLN 73267,2265 To: Tim Oren 76703,202 An obvious but maybe gentle reminder. Before submitting bugs to the compendium it would be helpful for contributors to check that the 'bugs' still exist in the current environments. "Bugs" that I have catalogued in my system have disappeared over time as various upgrades in software etc have occurred here. Unfortunately my aged memory plays tricks on me and I find myself avoiding nonexistent or antiquated pitfalls. #: 11116 S2/GEM Support 06-Sep-86 00:16:28 Fm: Corey Cole 76224,66 To: Tom Jeffries 73717,2261 We have a kludgey solution -- depending on one of our state variables, we either use vq_mouse or graf_mkstate (the AES equivalent). I have no idea why vq_mouse works at some times and not at others, which makes me very nervous! Fortunately, at least so far, the situations in which vq_mouse can't be used are also those in which response time is not critical. You should stick with graf_mkstate if you can handle the slow "feel". #: 11108 S0/General 05-Sep-86 20:25:17 Fm: OZZIE BOESHANS 73157,2672 To: [F0] SYSOP 76703,2010 If I have a dialog box with a button in it and the button is defined as an EXIT button but not selectable, should pointing at it and clicking cause form_do to want to be able to have a big button that I can click on and exit from form_do but I don't want it turned to reverse video when it is selected. I have found that unless the button is defined as EXIT and SELECTABLE form_do does not exit when the button it clicked. Any ideas? Thanks in advance for any help! #: 11120 S2/GEM Support 06-Sep-86 03:27:52 Fm: Don Curtis 76703,4321 To: SYSOP*Dave Groves 76703,4223 Dave, evnt_button(etc....) locks you in never-never land IF while waiting for the button event, you move the mouse into the menu bar. There is a work-around, you do an evnt_multi(etc...) looking for both the button event AND the timer event with a time value of 1ms. The C code for the workaround goes like this: while(evnt_multi(MU_BUTTON | MU_TIMER, .etc...) == MU_TIMER); As you can see, you will only exit this routine when the button has been pressed. Moving into the menu bar will not lock you with this work-around. #: 11121 S2/GEM Support 06-Sep-86 05:07:00 Fm: Dan Rhea 71777,2337 To: SYSOP*Dave Groves 76703,4223 Well here's one that has bothered me for a long time though it may be a feature rather than a bug. When using a file selector box, and you have selected a file at the bottom of the list (the slider has been moved down from the top). You select the file and all is well. Now you call up the selector again but this time you are sent back to the top of the selector and need to go searching for where you left off. Is it possible for a selector box (even optionally), to be able to remember its previous state. Dan Rhea, 71777,2337 #: 11128 S2/GEM Support 06-Sep-86 12:30:24 Fm: Stephen Mehalek 73277,2557 To: SYSOP*Dave Groves 76703,4223 The modulus operator that comes with VDIBIND library is incorrect. The lrem.o object module contains 144 bytes and produces results of zero when it is used to give the remainder of long integers. The fix is to take the lrem.o module from the GEMLIB object modules and move it to the VDIBIND libraries. Use the AR^ AR68 utility routine to do this. This bug is not a GEM bug, but most people owning the developers package should know about this. #: 11137 S2/GEM Support 06-Sep-86 18:30:21 Fm: OZZIE BOESHANS 73157,2672 To: 76703,4224 Is there any way to keep a button in a DIALOG box from going reverse video when it is selected? Also, is there a way to set the state of the mouse buttons. I have an application that for some reason thinks the button is still down after a press and release sometimes. Pressing and releasing the button clears the condition. What happens is that I select an option that causes a dialog box to appear and once in a while when I move the mouse to a button the button becomes reverse video before I even click. If I move to a different button the new button doesn't turn reverse video but if I go back to the original it goes reverse video. If I click anywhere else on the screen and then re-enter the first button it no longer goes reverse video. This really has me frustrated. Thanks for any help that is given. #: 11166 S2/GEM Support 07-Sep-86 21:01:48 Fm: David Beckemeyer 74236,625 To: Corey Cole 76224,66 I've noticed that the lines between when you should (can) use VDI calls and when to use AES are somewhat fuzzy. Is this documented anywhere that you know of? #: 11173 S2/GEM Support 07-Sep-86 22:32:42 Fm: Corey Cole 76224,66 To: David Beckemeyer 74236,625 I don't know of any documentation on [when to use VDI vs. AES calls]. In general, any display operation can use either/both, while input should be restricted to one or the other (if the AES is used at all, your program should only do input with AES calls). The catch is that AES is frequently less efficient than VDI, sometimes (as with graf_mkstate) by major amounts. #: 11167 S0/General 07-Sep-86 21:13:31 Fm: David Beckemeyer 74236,625 To: Ric Clayton 73317,1350 Ric, assuming there isn't a simpler, plain old bug, in your program, it looks like you may be running up against the classic GEMDOS getting confused bug. I have seen this sort of problem, (GEMDOS unable to open, or create a file for no apparent reason), and I have traced it some internal data structure handling bugs in GEMDOS. It seems than GEMDOS keeps a copy of the directory tree structure of each disk, and as you access directories continually adds to this data structure. The idea is to make file accesses faster by avoiding reading each directory in the tree of a file spec whenever a file is accessed. So far so good, but under some circumstances, which seem to relate to the number of directories accessed (across all drives), and I think also related to floppy disk media changes, this internal GEMDOS data structure gets messed up, and GEMDOS doesn't know where to put the next link in its structure, and goes out to lunch forever. I don't know the whole solution to this problem, but I have been able to reduce its frequency by making an undocumented BIOS call at certain times, which seems to force GEMDOS to free some internal memory. I found it by catching the desktop making BIOS calls. I don't have the code in front of me, but maybe John Feagans @ Atari could help? If not, I'll look it up and leave you a message. - david #: 11026 S0/General 04-Sep-86 01:31:42 Fm: Ric Clayton 73317,1350 To: All Hi there, I have written a program to backup files from my hard disk to a floppy disk and have run into a problem I can't seem to get around. The program is rather simple; it just copies files from a source directory to the same directory on a designated floppy drive, creating directories as needed, using GEMDOS calls. Nothing fancy, just regular DOS type file copies. So the program goes chugging alone, happily copying files and all of a sudden gets an "file not found" error (-33) when it tries to open the Source file for reading, the name of which it just got from a directory scan! After this occurs, GEMDOS seems to be completely dorked and strange things start to happen, requiring a re-boot to restore it to normalcy. It doesn't always happen, and when it does it's not always in the same place. Sometimes I can get through a whole 5MB partition with no mishap. Sometimes I can't even get through the files in the root directory. I have gone over and over the code and can't find any error that would cause this. However, I'm new to both the ST and 'C' programming environments and may have made some false assumptions, so I'm asking for any help I can get. I would be glad to upload the source code if anyone would like to give it the once over. The program doesn't use GEM, just gemDOS (or is it TOS?). (I've compiled it with Megamax-C and Mark Williams C and get the same error. Though I haven't tried Alcyon-C yet.) Thanks in advance for your help. #: 11196 S2/GEM Support 08-Sep-86 12:30:21 Fm: Jim Needhan, DRI 76703,1064 To: Corey Cole 76224,66 I assume the confusion is with "mouse" calls and the such... The AES should always be used rather than the VDI when making mouse or other hardware calls. I have heard the complaints about speed but I do not fully agree with those programmer's with the concerns. I do realize that there is a speed "hit" but what is gained is a program that is more reliable and more portable. The AES cannot keep track of what the VDI is doing so by going through the AES the "system" is aware of what is going on. Of course, you may write directly to the VDI and in graphics display calls etc, it is the correct path, but, for windowing, mouse control, etc. it is better from the DRI point of view to go through the AES. Portability? There will be GEM available for other environments, and announcements will be made as appropriate, so don't lock yourself out if it isn't necessary. #: 11219 S2/GEM Support 08-Sep-86 22:13:27 Fm: SYSOP*Tom Hudson 76703,4224 To: Jim Needhan, DRI 76703,1064 Right you are, Jim. The VDI mouse routines are great because they are not affected by the DCLICK speed setting, but the system goes "HUH?" if you try to intermix the VDI and AES mouse calls. My solution: if you are doing a mouse operation that won't be declicked, before the mouse is used set the dclick speed to its fastest speed and restore it afterwards. Thanks for the help. Oh, do you guys have any information on writing custom GDOS device drivers (like printers and custom screen devices)? If so, I'd like to get the info if I may. I'd appreciate it. #: 11248 S2/GEM Support 09-Sep-86 01:10:50 Fm: Corey Cole 76224,66 To: Jim Needhan, DRI 76703,1064 Jim, I guess I didn't make myself totally clear. When I was complaining about "speed hits" when using the AES to read the mouse, I didn't just mean response delays (although those are bad enough). We're talking actually failing to recognize events -- for example, if the user presses the left mouse button in an application using graf_mkstate, the application will not be notified unless the button remains depressed for a sizable fraction of a second. I believe the same is true with evnt_multi. This behavior can be seen in many GEM applications (Megamax editor, DEGAS, etc.) -- user has to hold down the button for about a second to get a new cursor (or whatever). Highlighting (in FLASH, megamax editor, my word processor until I went over to vq_mouse, etc.) also "feels" jerky to the user because the program isn't immediately notified. At the GEM seminar last year, I was told that evnt_multi does not wait the double-click time if the mouse moves more than a pixel or two. This simply doesn't seem to be the case (it should be), in my observation. In general, mouse events have a "clunky" feel to the user, which tends to hurt the "feel" of the entire application. Sorry to drag this into the ground, just not sure how clearly I'm stating this! -- Corey #: 11252 S2/GEM Support 09-Sep-86 03:23:11 Fm: Alan Page 72227,3507 To: Corey Cole 76224,66 I agree with you about the slowness of evnt_multi in picking up button clicks. Flash 1.1 uses a complicated kludge involving a mixture of vq_mouse and ev_mmobutton which gives it _immediate_ response for cursor positioning. - Alan #: 11203 S2/GEM Support 08-Sep-86 13:18:40 Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223 Here are a few 'goodies' we know about: First some bugs: -If you use a regular "form_do" in a desk accessory, you may find that your keys 'fall through' to the application, so be prepared to write your own. Falling through means that if you have a desk accessory on top of a word processor for example, keys pressed during a form in the desk accessory would be picked up and used by the word processor. -Evnt_timer is a very dangerous call to make from a desk accessory; it sometimes causes the entire program to freeze up. Regarding timers see the following message from Chris. - The system exception handler has some bugs. (See the following message from Chris) -Appl_play and record do not work without a ROM patch from Atari. -Alcyon Compiler problems. Appl_init returns the wrong value (always returns 1). -The documentation for Vex_motv is wrong - it requires a jump to the saved address to update the driver. Some things to remember: -Before doing an fsel_input call, and before any I/O, make sure you have set path names (A: is not good enough, it must be A:\), or be ready for a freeze. -Form_alert strings can only be about 30 characters per line. -You should modify the source of form_do (form_keybd) to change underscores to dashes; underscores blows your application out of the water. #: 11204 S2/GEM Support 08-Sep-86 13:20:55 Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223 There are 2 serious bugs related to desk accessories. Both were reported to Atari months ago. 1. EVNT_TIMER is flaky. The timer event will not always return when called. This seems to happen most often when there is heavy disk activity, but not always. If you do an evnt_multi() with messages and timers, the timers will eventually hang up, but if the accessory receives a message, the timers start working again (for a while). We call this burping the timer. As a programmer, this means that you must find an alternate way of releasing control (it isn't easy). That's why some desk accessories degrade the system performance so much. This bug has been ported from the IBM PC version of GEM. 2. The system exception handler has one or more bugs. If an application generates a system alert (drive not responding, insert your new A: disk, etc.), any desk accessory that is running is not stopped. That is, if you have an accessory buzzing along waiting for evnt_timers (which you shouldn't), or mouse movement events (actually any evnt_ function has this problem), the multitasking of the desk accessories is not turned off while the alert is presented. I checked this out with an accessory that woke up constantly and wrote a counter to the screen. As soon as the alert is cleared, the desk accessory, then the application bomb. I suspect it's because the accessory gets running in supervisor mode and messes up the super stack or something like that. The same thing can happen in a one drive system in another way (this is probably a separate bug). If the desk accessory reads from drive B:, and the system alert is generated to swap diskettes, after the alert is cleared first the desk accessory then the application will bomb. We've even seen it bomb the GEM Desktop.-- Chris Bailey (Batteries Included) #: 11232 S2/GEM Support 08-Sep-86 23:33:36 Fm: Rich Plom (Intersect) 73307,1676 To: SYSOP*Dave Groves 76703,4223 You want bugs, use the file selector. It is one of the most flawed things in the system. You can crash it two ways, put the '_' in the path. Or, you can just leave a disk out and wait two times for it to give the abort continue error, after that booomb! Also, when you have a single drive system and you try to treat drive b as disk b, it really gets strange. #: 11267 S2/GEM Support 09-Sep-86 11:39:02 Fm: Ken Settle 76556,753 To: SYSOP*Dave Groves 76703,4223 I have noticed the following bugs in GEM: Bug series #1: (AES object library section) In the TEDINFO structure, te_pvalid field, the following validation characters DO NOT work properly: 9, A, a, N, n, P, p, (all except F and X). The bug occurs when a form_dial is called with an object containing any of the above characters in the PVALID field. If the user types an underscore "_" on any character position (except the last), the system promptly "bombs" out. The bug with the "F" character in that situation was fixed in ROM TOS and the "X" character never had this problem (to my knowledge). Also in the TEDINFO structure, the te_txtlen and te_tmplen fields both contain the length+1 of their respective strings, contrary to the documentation. Bug series #2: (GEMDOS section) Hard disk file WRITE time increases by roughly 1 second for each megabyte stored on that drive (partition, whatever). This is probably due to unspeakably slow FAT search code (it takes about 450 times as long as it would using two simple 68000 instructions to search a FAT sector). Dfree() command takes "next to forever" on the hard drive. It is somehow possible to get a folder (on the hard disk) that is impossible to delete, even though it's empty. - Ken Settle [76556,753] #: 11268 S2/GEM Support 09-Sep-86 11:42:38 Fm: Ken Settle 76556,753 To: Ken Settle 76556,753 Bug series #3: (GEM Desktop section) SOMETIMES when you close a directory window and re-open it from another drive, the window decides to exactly cover up the top window on the screen. This has been a major annoyance causing me to be paranoid about closing a directory window. It seems to be very random (as all truly good bugs are). Changing resolution and/or colors can really screw up the desktop when you return to it. It should be Desktop's responsibility to make sure these conform to the current defaults. Desktop should also automatically set ALL DESKTOP.INF defaults on power up, and allow ANY application or accessory to have access to/modify these defaults (palette, key rate, RS232/Printer setup). Desktop should be hardy enough to survive a "close workstation" call by an application, without losing it's "pull-down menu" capability. This might allow VDI to be used in any resolution as dictated by the application, not desktop. It should be possible to abort a multiple-file COPY or DELETE operation at any time using the mouse and/or keyboard. Bug series #4: ("TOS" section) An error box stating "TOS ERROR #35" means nothing to most people, what's the real message? Bug series #5: (AES/VDI section) The dot-pattern in the move bar of a window can get screwed up by a redraw attempt such as after a dialog has disappeared. It appears to happen because of the "blit" feature being used to move a window to any odd line/pixel where VDI can't accurately match up the pattern. - Ken Settle [76556,753] #: 11307 S2/GEM Support 10-Sep-86 00:26:44 Fm: Dan Rhea 71777,2337 To: SYSOP*Dave Groves 76703,4223 Here is another interesting one I've stumbled on. It is not a "GEM" bug but a bug in the C Runtime (GEMLIB), or the AS68.PRG step of the latest and greatest compiler. This has been driving me nuts till I finally isolated it to the following test case. The test works fine with the old compiler/runtime but gives bad results for the new one (i.e. every other long has a value of 0). main() { long int a, b, c, d; int i; a = b = c = d = 0L; for (i=0; i<25; i++) { a++; b++; c++; d++; printf ("a=%D b=%D c=%D d=%D\n",a,b,c,d); } Cconin (); /* Wait for any character */ } Good Results: a=1 b=1 c=1 d=1 a=2 b=2 c=2 d=3 ... a=25 b=25 c=25 d=25 Bad Results a=1 b=0 c=1 d=0 a=2 b=0 c=2 d=0 ... a=25 b=0 c=25 d=0 Note: I included OSBIND.H in the above program too. Has anyone hit this one yet or devised a workaround (other than floating point or the obvious two longs for each one used). Dan Rhea, 71777,2337 #: 11314 S2/GEM Support 10-Sep-86 09:38:33 Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223 Dave, As the GEM DESKTOP is simply a 'program' , I think its bugs should be kept separate. #: 11310 S2/GEM Support 10-Sep-86 00:43:55 Fm: Rich Plom (Intersect) 73307,1676 To: SYSOP*Dave Groves 76703,4223 Nope, the only way around them is to write your own file selector. Atari will someday weed the bugs out(hopefully). It is a shame that a solid program can be crashed by it. It looks like the authors fault to everyone else, but the blame is the operating systems. The one that gets me the most is when you forget to put a disk in or put it in crooked and it dies after the second retry. #: 11443 S2/GEM Support 12-Sep-86 00:14:24 Fm: Tom Jeffries 73717,2261 To: Jim Needhan, DRI 76703,1064 There's an old rule of thumb- if one person tells you you have a tail, don't bother to look. If ten people tell you you have a tail, you'd better take a look to see what's going on. Actually, I think most of us look when one person tells us we have a bug. There is a whole series of problems with reading the mouse which include: slow and inaccurate reading of the mouse buttons, especially from the AES, evnt_multi() will not read both mouse buttons (as far as I know that's not in the bug list yet, we should add it), mouse button releases are not always recognized, etc. etc. etc. I must admit I'm getting a little tired of DRI and Atari trying to blame these problems on their bad code. Too many developers are having the same problems for it to be bad code. In an earlier note, you defend the slowness of evnt_multi. If it really were accurate, I might go along. However, even if that were the case, it is hard to ignore the fact that the Mac, which also has to read double clicks, feels much less clunky than the ST. GEM, like all operating systems, has some problems. Actually, if you compare it with MS-DOS, which is much simpler but also has lots of bugs, you guys at DRI and the folks at Atari did a terrific job, especially considering the time it took to get the machine on the market. No purpose is served, however, by trying to blame bad code for problems that are real and don't seem to be getting solved. I don't mean to cause offense- but since we have the benefit of having some of the people who wrote GEM online, I would like the discussion to be at a realistic level. Thanks, #: 11445 S2/GEM Support 12-Sep-86 00:18:23 Fm: Tom Jeffries 73717,2261 To: Mark Skapinker (BI) 76703,207 One more bug- despite the documentation, you cannot read both the left and the right mouse button with one evnt_multi() call. You have to use two, which gives you time to go out for dinner before the mouse button event is reported, or use a different call. #: 11456 S2/GEM Support 12-Sep-86 16:24:52 Fm: Michael T. Smith 73317,3470 To: Mark Skapinker (BI) 76703,207 OK, I want in this mesh of messages... I just yesterday started writing a ml routine to be used in the vex_motv function. I had heard of some bugs in the vq_mouse and my program has been slipping in the area of mouse handling.. So, the problem occurred when it hits the vex_motv it gives me 2 bombs and I don't know why, I haven't looked on Dl2 yet but I will to see if my problem can be answered there. (I think that's where you were going to put the compiled list of bugs) If it's simply in MY ml code then I will eventually find it, but if there is funny business in that routine I would like to know how to get around it. The only other thing I think I'll be able to answer myself: Desk Acc's. I know that if I get a message 20 then I need to redraw. Is that It? If you have any Advice simply give it. I appreciate your help. Thanks.... Michael T Smith Xetec Inc. Salina Ks 73317,3470 #: 11483 S2/GEM Support 13-Sep-86 10:55:39 Fm: Tom Jeffries 73717,2261 To: Michael T. Smith 73317,3470 One more bug (There's always one more bug), I think this one is pretty well known and documented but it can be unpleasant if you don't know about it: fsel_input() resets the clipping rectangle and does not reset it on exit. It's easy to work around- you just set your own clipping area when you regain control. #: 11539 S2/GEM Support 13-Sep-86 22:58:44 Fm: Alan Page 72227,3507 To: [F7] SYSOP*Dave Groves 76703,4223 Here's another bug for the list. When I use the function appl_find (from a desk accessory) it should return -1 if the application is not found. However, if I call appl_find with the name of an application just after I exit it, I get a 'valid' ID. As soon as I run another application then I get the proper -1 value returned. It acts like the name of the application is not erased until you run another application. - Alan #: 11540 S2/GEM Support 14-Sep-86 01:37:43 Fm: SYSOP*Tom Hudson 76703,4224 To: [F7] Alan Page 72227,3507 By golly, Alan -- you have the same bug as I found yesterday!!! I was working on a desk accessory that looked for DEGAS Elite, and it works fine until Elite is run. That is, it knows it's not there before Elite is run, but thinks it's there after Elite's done! Fortunately, The accessory is written so that that does not matter, but it is a bug that should be reported. #: 11641 S2/GEM Support 16-Sep-86 08:47:54 Fm: Michael T. Smith 73317,3470 To: SYSOP*Russ Wetmore 76703,2010 Russ, Thanks for the info.. I am using the 'asm{...}' from megamax for my interrupt interrupt but also 'C'... mint() { asm{...} }. The problem now exists that as soon as I call the vex_motv(num1,,); it crashes (2 bombs:Bus error) then returns to the desktop where it sits until I move the mouse and then I get 4 bombs.. (Illegal inst.) Currently, my int. is only a nop which leads me to believe that it is not caused by my int, but by the way I am calling the vex_motv();. I saw something about having to call , or jump to, the location that the function returns to you. Also I noticed once that it executed the next 'C' instruction after the vex_motv. Go FIgure? Well, if any of this sounds familiar than let me know. Michael T Smith... Xetec Inc. #: 11667 S2/GEM Support 16-Sep-86 22:23:41 Fm: SYSOP*Russ Wetmore 76703,2010 To: Michael T. Smith 73317,3470 There's an example of calling vex_timv in DL0 someplace that I uploaded. The procedure should be similar for vex_motv if you'd like to look at it. [ Russ ]