> has anyone been able to duplicate the reported instability
I don't think I reported it to the list.
But as it happens I have just completed some more testing on machines
other than my (somewhat anomalous) duo 2300.
First the bad news:
1) I found the same instability that I had on the duo
i.e. when the server app is frontmost it is not too long before a
crash occurs - I found this with both the standard vncPatches and
my vncPatches68k. However, note that it seemed slightly more
crashable with the standard vncPatches (I suspect this could be
due to the more extensive non-reentry requirements I have put in
the code).
Another point of note is that I found the symptoms after crash
depended on the action when the crash occurred.
i.e. if it crashes when I click, then the cursor may continue to
be moveable straight after, but nothing happens when clicking.
Alternatively, if the crash occurs only while the cursor is moving
then the cursor stops moving (but it's rather hard to tell if there
is no response when clicking...)
2) Double-clicking in the Finder is improved somewhat, but still quite
unreliable (except on my duo, of course...)
I very strongly suspect this is *not* a CursorDevice debouncing
problem, as was originally suggested (after all, double-clicks seem
to work elsewhere), but is actually because of the way that the
Finder 'locks up' the machine for a fraction of a second after a
click on an icon (after some testing I realised the length of time
is dependent on the 'double-click' time set in the Mouse control
panel - this suggests that the Finder is taking over monitoring of
the mouse after a mouse-down so that it can check for various
things like contextual menus etc - it might be worth trying with
this switched off to see if the problem persists).
3) With the removal of the interrupt code that allowed receiving of
information at interrupt time, there are a few minor oddities with
regard to cursor tracking on slower Macs (for example, with the
'drag-selection' of icons - the 'elastic-band' sometimes does not
appear when it should).
Now the good news:
1) Apart from the above problem (which only seems to happen when the
server app is frontmost) the alpha 3 release does appear to be very
robust.
2) The encoding bugs have been dealt with (the background problem and
the occasional rect errors, as well as CoRRE now being correctly
activated).
3) The hardware cursor looks like it is working well.
Of course, the drag problem remains (are you getting anywhere with
that, Jonathan?) with the standard vncPatches.
With regard to an alpha 3 version of vncPatches68k, I have completed
a version, but I'm finding a rather odd case where it occasionally
misses some updates - you have to wipe across with the cursor to see
it. I don't know why this should be (yet) since the coding for the
update capturing (and buffering etc) has not changed since alpha 1.
If you want to try it out in its current state you can download it
as follows:
http://wrench.et.ic.ac.uk/adrian/software/vnc/vncPatches68k-a3.hqx
There's also some anomalous problems I've been having with the
modifier keys (the shift key in particular - rather odd, again, but
I suspect it has to do with the way that the server app and the
patches are interacting together on the low level keymapping stuff).
Anyway, let me know if you can replicate the above crashes, and
also if you try vncPatches68k, how you get on with it...
Thanks!
Adrian
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
