f



Mouse cursor in OS2 full-screen sessions

Hi all,

As a follow up to my previous mouse thread, I can now report
that mouse support for OS2 works quite well in my text-mode
user-interface library (as used by DFSee) on OS2.

However, I have not found a soluaton to get a mouse-cursor
displayed in an OS2 full-screen session.

The documented (AFAIK :-) method is to use the MOU function
MouDrawPtr( handle) after opening the mouse to get that handle.
I do that in the main (initializing) thread now, and it does not
seem to have any effect at all.


This might be a threading issue, or perhaps a 16-bit versus 32-bit
issue, since it is a 32-bit program calling the 16-bit MOU API's.

However, the rest of the API's seems to work just fine.

In the ideal scenario I would hide and unhide the mouse-cursor
when the main thread would starting waiting for input.
Since this is in a different thread from the MouReadEventQue()
that is in the mouse thread waiting for input there, I would assume
that it needs a DosIOCtl instead of a MOU call to avoid the
deadlock problem ith the non-reentrant MOU subsystem.

If anyone has some code-example or other advise on
how to tackle this, I'd much appreciate it!

Note that the mouse DOES work in a full-screen session, 
it is just the cursor that is missing ...


TIA, JvW

PS:
The mouse cursor in windowed sessions (VIO) is the
normal graphics cursor, and is accurate in its position.
I would asume that the DrawPtr() API does not do anything there ???

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
6/27/2005 9:27:42 PM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

80 Replies
580 Views

Similar Articles

[PageSpeed] 2

 > However, I have not found a soluaton to get a mouse-cursor
 > displayed in an OS2 full-screen session.

Here's a stripped-down snippet which seems to work for me.

BOOL fState=FALSE,keuze_gemaakt=FALSE;
HMOU hmou;
MOUEVENTINFO mouev;
NOPTRRECT mourt={0,0,rijen-1,kolommen-1};
PTRLOC moupl;
USHORT i,j=0,wacht=0;

MouOpen(NULL,&hmou);
moupl.col=cursorx;
moupl.row=cursory;

MouSetPtrPos(&moupl,hmou);

MouDrawPtr(hmou);

do
   {
   MouReadEventQue(&mouev,&wacht,hmou);
   if(mouev.time)
      {
      if(mouev.fs&buttonsmasker)
         {
         keuze_gemaakt=TRUE;
         break;
         }
      }
   }while((!keuze_gemaakt)&&stoppen1==0);

MouClose(hmou);
 
 > Note that the mouse DOES work in a full-screen session, 
 > it is just the cursor that is missing ...
 
As mentioned earlier, there's a versoin of MOUSE.SYS which shows that
behaviour when a mouse cursor is displayed more than once. Another
possible resource:

\ibmcpp\samples\toolkit\os2\consolio



---
0
spamgate
6/27/2005 9:49:27 PM
Hi,

are you using SNAP ? I am asking as I have it installed and the exact 
same problem than you while others do not seem to have the problem.
I have written this very simple app:

#define INCL_BASE
#include <os2.h>
#include <stdio.h>
#include <string.h>

int main(int argc,char *argv[])
{
     CHAR buf[256];
     MOUEVENTINFO mouevEvent;
     PTRLOC mouplPosition={0};
     APIRET16 rc;
     HMOU hmou=NULLHANDLE;
     USHORT fWait=TRUE;

     rc = MouOpen(NULL,&hmou);
     rc = MouFlushQue(hmou);
     rc = MouSetPtrPos(&mouplPosition,hmou);
     rc = MouDrawPtr(hmou);
     do
     {
         memset(&mouevEvent,0,sizeof(mouevEvent));
         rc = MouReadEventQue(&mouevEvent,&fWait,hmou);
         sprintf(buf,"Event %#x\r\n",mouevEvent.fs);
         VioWrtTTY(buf,strlen(buf),0);
     }
     while(mouevEvent.fs != MOUSE_BN2_DOWN);
     rc = MouClose(hmou);
     return 0;
}

which looks just like the other suggestion but it won't display the 
cursor but only occasionally (where I think it depends on the session 
switch).
I guess it's some error in the base video support 
(screen01.sys,bvhvga.dll,bvhsvga.dll).
I tried it both, as a full screen app and as a windowable app.

Lars


Jan van Wijk schrieb:
> Hi all,
> 
> As a follow up to my previous mouse thread, I can now report
> that mouse support for OS2 works quite well in my text-mode
> user-interface library (as used by DFSee) on OS2.
> 
> However, I have not found a soluaton to get a mouse-cursor
> displayed in an OS2 full-screen session.
> 
> The documented (AFAIK :-) method is to use the MOU function
> MouDrawPtr( handle) after opening the mouse to get that handle.
> I do that in the main (initializing) thread now, and it does not
> seem to have any effect at all.
> 
> 
> This might be a threading issue, or perhaps a 16-bit versus 32-bit
> issue, since it is a 32-bit program calling the 16-bit MOU API's.
> 
> However, the rest of the API's seems to work just fine.
> 
> In the ideal scenario I would hide and unhide the mouse-cursor
> when the main thread would starting waiting for input.
> Since this is in a different thread from the MouReadEventQue()
> that is in the mouse thread waiting for input there, I would assume
> that it needs a DosIOCtl instead of a MOU call to avoid the
> deadlock problem ith the non-reentrant MOU subsystem.
> 
> If anyone has some code-example or other advise on
> how to tackle this, I'd much appreciate it!
> 
> Note that the mouse DOES work in a full-screen session, 
> it is just the cursor that is missing ...
> 
> 
> TIA, JvW
> 
> PS:
> The mouse cursor in windowed sessions (VIO) is the
> normal graphics cursor, and is accurate in its position.
> I would asume that the DrawPtr() API does not do anything there ???
> 
0
Lars
6/28/2005 8:47:50 PM
On Tue, 28 Jun 2005 20:47:50 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
Hi Lars,

> are you using SNAP ? I am asking as I have it installed and the exact 
> same problem than you while others do not seem to have the problem.
> I have written this very simple app:

No, I am using the regular (eCS 1.2 level) scitech driver.

I don't think it has to do with the mouse or video driver since 
FC/2 displays the cursor correctly (in a full screen session)

==> UPDATE:

I just retested my latest DFSee version and now it DOES display
a mouse cursor, so perhaps the behaviour is erratic like
it seems to be on your system/your program too.

The only problem is now that is clobbers the screen a bit, since it
is not removed/redisplayed while the program redraws  the windows :-)

That can only be solved by hiding/drawing the cursor from the main
thread which will require a DosIOCtl instead of a direct MouDrawPtr
call (since that would hang).


Anyway, seems there is some progress :-)


Thanks, JvW


-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
6/28/2005 9:02:00 PM
 > are you using SNAP ? I am asking as I have it installed and the exact 
 > same problem than you while others do not seem to have the problem.

Same problem here, with eCS. 'Strange', it used to work with Warp 4
just fine. I have to say it looks like the old MOUSE.SYS problem to
me. The mouse cursor is there, but it isn't visible. If possible you
could try the original MOUSE.SYS (backup the existing MOUSE.SYS first,
obviously) of Warp 4, and see if that solves anything. Other than that,
it could me SNAP too.



---
0
spamgate
6/28/2005 10:36:42 PM
ML wrote:

> Other than that, it could me SNAP too.
> 
  No it couldn't, because it has absolutely nothing to do with drawing 
the mouse cursor. It is however not unthinkable that some of the IBM 
DLLs distributed with SNAP might be responsible (BVHSVGA etc.).


          Michal

0
Michal
6/28/2005 11:46:38 PM
On Tue, 28 Jun 2005 21:02:00 UTC, "Jan van Wijk" <jvw.no.spam@dfsee.com> wrote:

> I just retested my latest DFSee version and now it DOES display
> a mouse cursor, so perhaps the behaviour is erratic like
> it seems to be on your system/your program too.

The behaviour IS ERRATIC.

Sometimes there is a mousecursor, but most of the times there is not.
I have not found a pattern yet.

Strange thing is, FC/2 always displays it correctly, 
so it does not seem to be a driver issue.

My mouse initialization code (main thread) looks like:

      if (MouOpen(NULL, &txw_hmouse) == NO_ERROR)
      {
         MouSetPtrPos( &mousepos, txw_hmouse);  // mouse to 0,0

         mask = TXOS2_MOUSEEVENTMASK;           // report all except move
         MouSetEventMask( &mask, txw_hmouse);
         mask = TXOS2_MOUSEDRAWMASK;            // Draw by driver, not appl
         MouSetDevStatus( &mask, txw_hmouse);

         MouFlushQue( txw_hmouse);
         MouDrawPtr(  txw_hmouse);              // show mouse cursor

         TxBeginThread( TxOS2MouseReader, READERSTACKSIZE, NULL);
         TRACES(( "Mouse opened, reader thread started ...\n"));
      }


And the MouseReader thread basically loops:

   while (1)                                    // keep running ...
   {
      wait = MOU_WAIT;
      MouReadEventQue( &mouInfo, &wait, txw_hmouse);

      // put event in an in-memory event-queue

   } 


-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
6/29/2005 9:51:10 AM
 >> Other than that, it could me SNAP too.
 
 > It is however not unthinkable that some of the IBM DLLs
 > distributed with SNAP might be responsible (BVHSVGA etc.).

That's what I ment, since Lars' described it that (and your) way.
Sorry for any confusion caused by the way I copied his statement.

The EXAMPLE.CMD in http://hobbes.nmsu.edu/pub/os2/dev/rexx/mruntime.zip
run in a FS (and VIO) session shows the problem with my copy of eCS 1.2.
IIRC it used to work with Warp 4 (and Warp 3 prior to a certain fixpack
or was that already Warp 4).

IIRC/2 the problem with the Warp [3|4] mouse cursor was slighly
different, it showed up for the first time it was used and never
again. IIRC/3 I never saw a mouse cursor in a VIO session, it's
FS I'm most worried about.

If one wants to exclude MOUSE.SYS to be (part of) the problem, one
could try to run the EXAMPLE.CMD mentioned above, using eCS/'SNAP'
but with the original MOUSE.SYS of Warp [3|4]. 



---
0
ML
6/29/2005 9:59:20 AM
 > The behaviour IS ERRATIC.

It is. Would a switch to the 32-bits equivalents solve issues
like this, i.e. not use the Mou*-API's?



---
0
ML
6/29/2005 10:12:15 AM
On Wed, 29 Jun 2005 10:12:15 UTC, ML <spamgate@hotmai1.com> wrote:

> > The behaviour IS ERRATIC.
>  
> It is. Would a switch to the 32-bits equivalents solve issues
> like this, i.e. not use the Mou*-API's?
  
And how would you do that ?
I was not aware there ARE any 32 bit equivalents ...

(except in 3rd party replacements, that have other problems for me :-)

Regards, JvW 

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
6/29/2005 6:28:17 PM
 >>> The behaviour IS ERRATIC.
  
 >> It is. Would a switch to the 32-bits equivalents solve issues
 >> like this, i.e. not use the Mou*-API's?
  
 > And how would you do that ?
 > I was not aware there ARE any 32 bit equivalents ...

I belive there aren't always 32 bit equivalents available, and please
do keep in mind I'm insulting programmers when I'ld call myself a
programmer too, but that should be category 07x of the IOCtl commands.

Control Porgram Guide and Reference ->
Generic IOCtl Commands ->
Category 07h

If you get it in a comparable working state, would you mind posting a
working skeleton like Lars' example, from DosOpen() upto and including
the closing ceremony?



---
0
spamgate
6/29/2005 8:18:39 PM
ML schrieb:
>  >> Other than that, it could me SNAP too.
>  
>  > It is however not unthinkable that some of the IBM DLLs
>  > distributed with SNAP might be responsible (BVHSVGA etc.).
> 
> That's what I ment, since Lars' described it that (and your) way.
> Sorry for any confusion caused by the way I copied his statement.
> 
> The EXAMPLE.CMD in http://hobbes.nmsu.edu/pub/os2/dev/rexx/mruntime.zip
> run in a FS (and VIO) session shows the problem with my copy of eCS 1.2.
> IIRC it used to work with Warp 4 (and Warp 3 prior to a certain fixpack
> or was that already Warp 4).
> 
> IIRC/2 the problem with the Warp [3|4] mouse cursor was slighly
> different, it showed up for the first time it was used and never
> again. IIRC/3 I never saw a mouse cursor in a VIO session, it's
> FS I'm most worried about.
> 
> If one wants to exclude MOUSE.SYS to be (part of) the problem, one
> could try to run the EXAMPLE.CMD mentioned above, using eCS/'SNAP'
> but with the original MOUSE.SYS of Warp [3|4]. 

I am using Warp 4 and AMOUSE (where AMOUSE replaces MOUSE.SYS by its own 
AMOUSE.SYS) and as I said it does not work here.
So either AMOUSE.SYS exhibits the same error as MOUSE.SYS or (which was 
what I meant with "SNAP") one of the base VIDEO DLLs and/or screen01.sys 
  are working incorrectly (this would be my suspicion).

Lars
0
Lars
6/29/2005 9:09:39 PM
 > I am using Warp 4 and AMOUSE (where AMOUSE replaces MOUSE.SYS by
 > its own  AMOUSE.SYS) and as I said it does not work here.
 > So either AMOUSE.SYS exhibits the same error as MOUSE.SYS

AFAICT now, restoring the original MOUSE.SYS was a solution regarding
Warp 3 where a fixpack introduced the (or 'a similar') problem for the
first time. I just moved and the Warp 3 CD is 'somewhere', so I cannot
check now if that one would work for me.

 > (which was what I meant with "SNAP")
 
Me too, but I may have been too brief for Michael. Never mind.

 > one of the base VIDEO DLLs and/or screen01.sys are working
 > incorrectly (this would be my suspicion).

The problem looks different, but that's just the part regarding not
diplaying the mouse cursor the first time. That always used to work.
Restoring an old copy of MOUSE.SYS may not work at all, it's just easy
to exclude and could be worth mentioning. That doesn't mean that I don't
think it's 'SNAP'. You could be right indeed.

BTW, a windowed VIO session never had a FS-like mouse cursor. Right?
I never tried that before eCS, docs saying that wouldn't work so I went
to a lot of trouble to always make my apps run FS. :-(



---
0
spamgate
6/29/2005 9:36:37 PM
ML schrieb:
>  > I am using Warp 4 and AMOUSE (where AMOUSE replaces MOUSE.SYS by
>  > its own  AMOUSE.SYS) and as I said it does not work here.
>  > So either AMOUSE.SYS exhibits the same error as MOUSE.SYS
> 
> AFAICT now, restoring the original MOUSE.SYS was a solution regarding
> Warp 3 where a fixpack introduced the (or 'a similar') problem for the
> first time. I just moved and the Warp 3 CD is 'somewhere', so I cannot
> check now if that one would work for me.
> 
>  > (which was what I meant with "SNAP")
>  
> Me too, but I may have been too brief for Michael. Never mind.
> 
>  > one of the base VIDEO DLLs and/or screen01.sys are working
>  > incorrectly (this would be my suspicion).
> 
> The problem looks different, but that's just the part regarding not
> diplaying the mouse cursor the first time. That always used to work.
> Restoring an old copy of MOUSE.SYS may not work at all, it's just easy
> to exclude and could be worth mentioning. That doesn't mean that I don't
> think it's 'SNAP'. You could be right indeed.
> 
> BTW, a windowed VIO session never had a FS-like mouse cursor. Right?
> I never tried that before eCS, docs saying that wouldn't work so I went
> to a lot of trouble to always make my apps run FS. :-(

I am not 100% sure but I think it WILL NOT work in a windowable session 
as I believe the old 16-bit MOUSE API needs a "real" (and not only 
simulated) text mode for mouse cursor display but the rest (mouse 
events, mouse cursor positioning) seems to work ok (judging from FC).

It's easy to prove:

"markexe.exe NOTWINDOWCOMPAT fc.exe" and you will see the mouse cursor 
(and the app runs FS).
"markexe.exe WINDOWCOMPAT fc.exe" and the mouse cursor disappears (and 
the app runs in a text window).


Lars
0
Lars
6/29/2005 9:54:21 PM
[A complimentary Cc of this posting was sent to
Lars Erdmann 
<lars.erdmann@arcor.de>], who wrote in article <42c3188a$0$1124$9b4e6d93@newsread4.arcor-online.net>:

> It's easy to prove:
> 
> "markexe.exe NOTWINDOWCOMPAT fc.exe" and you will see the mouse cursor 
> (and the app runs FS).
> "markexe.exe WINDOWCOMPAT fc.exe" and the mouse cursor disappears (and 
> the app runs in a text window).

Obviously, what you write is wrong (you probably mean running markexe
followed by a click on an icon).  The same could be checked by running
FC in a command-line session (windowed or FS).

Anyway, this looks like a very roundabout way to

  start /fs/n  fc
  start /win/n fc

Hope this helps,
Ilya
0
Ilya
6/30/2005 4:44:14 AM
On Wed, 29 Jun 2005 21:36:37 UTC, spamgate@hotmai1.com (ML) wrote:
  
> BTW, a windowed VIO session never had a FS-like mouse cursor. Right?
> I never tried that before eCS, docs saying that wouldn't work so I went
> to a lot of trouble to always make my apps run FS. :-(
>  

Right, the block-shaped cursor is only displayed in a 
full-screen session, if at all.
That is for OS/2 sessions, I remember you could get both displayed 
(in slightly different positions :-) inside a DOS VDM window.


However, I don't see the need to run FS, for me that is just a 
requirement when booting from CD or diskette (no PM).

If you have a windowed VIO window, the normal graphic 
cursor accurately represents the mouse cursor.
(and looks much better anyway)

For an example (and to test the mouse cursor in FS)
you can now download DFSee version 7.07 that has
mouse capability. It works just fine in a VIO window:

	http://www.dfsee.com/dfsee7xx_os2.zip
or
	http:/www.dfsee.com/dfsee/dfsee7xx_warpin.exe


On FS, on most systems it seems hit and miss, but there
is one (also eCS 1.2) system that sofar ALWAYS displays
the mouse cursor correctly.
I have not found the difference yet, the mouse.sys
and BVH*.DLL files are identical.
AFAIK, so is the SNAP version (std eCS OEM level).

Of course the hardware (videocard) is different ...

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
6/30/2005 1:07:23 PM
On Wed, 29 Jun 2005 20:18:39 UTC, spamgate@hotmai1.com (ML) wrote:

> >> It is. Would a switch to the 32-bits equivalents solve issues
>  >> like this, i.e. not use the Mou*-API's?
>   
>  > And how would you do that ?
>  > I was not aware there ARE any 32 bit equivalents ...
>  
> I belive there aren't always 32 bit equivalents available, and please
> do keep in mind I'm insulting programmers when I'ld call myself a
> programmer too, but that should be category 07x of the IOCtl commands.
>  
> Control Porgram Guide and Reference ->
> Generic IOCtl Commands ->
> Category 07h

Ah, yes the IOCtl interfaces ...

I did test with those during my trial and error sessions, but did not
get a mouse-cursor then either AFAIK. The code to show the cursor was:

+++++ snippet
        ULONG        dummy   = 0;
        ULONG        ddata   = 0;
        ULONG        DataLen = sizeof(ddata);
        ULONG        ParmLen = sizeof(dummy);

        DosDevIOCtl( hmouse, IOCTL_POINTINGDEVICE, MOU_DRAWPTR,
                     &dummy, ParmLen, &ParmLen,
                     &ddata, DataLen, &DataLen);
+++++

One thing that may need some thought or experimenting here 
is the used handle, in that case I used the (16 bit ?) handle I got 
from the MouOpen() call, but that does not 'feel' quite right :-)

Most likely I should use DosOpen() on "MOUSE$" as 
peeking MOUSE.SYS  suggests and use that handle.
I have not found specific info on the handle to use 
(or parameter usage) for the mouse IOCtls anywhere ...

I have used the specs for the 16-bit MOU subsystem
as my best guess on parameters sofar :-)

I will need the IOCtl interface if I want to let the FS 
cursor play nice while redrawing the screen. 
(e.g. only display it while waiting for input).


I will continue experimenting with them a bit as soon 
as my DFSee support-backlog cleared up :-)

  
> If you get it in a comparable working state, would you mind posting a
> working skeleton like Lars' example, from DosOpen() upto and including
> the closing ceremony?


Sure, as a matter of fact, the whole windowing library (source), 
including this mouse support will be made available for other 
developers in the near future :-)

(I will present it as an example on the developers conference in Dresden)


PS:
all shown snippets have been compiled with Openwatcom 1.4,
I have not tried the VAC or other compilers ...

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
6/30/2005 1:34:49 PM
 > Ah, yes the IOCtl interfaces ...
 
 > I did test with those during my trial and error sessions, but
 > did not get a mouse-cursor then either AFAIK.

Perhaps a candidate for the most stupid remark ever made here, but
IIRC there was a package called something like RXANSI20.ZIP. That
used 'classic' ANSI codes with REXX to change colors, e.g. :

      SAY red_on_white 'Red characters, white background'

Nothing fancy, I assume it just filled the variable red_on_white
with the right ANSI consol I/O escape codes.

IIRC/2 that package also included a mouse function, which IIRC/3
looked slightly different from Mou* implementations, so then it
wouldn't be just a 'wrapper'. Does ANSI(.SYS) indeed include
support for a basic mouse funtion? If so, that could be 'the'
other way to get it working properly. No OS/2 PC available
here at the moment, so I cannot tell if RXANSI20.ZIP (?) works
properly here now. 



---
0
ML
6/30/2005 3:10:03 PM
 >> BTW, a windowed VIO session never had a FS-like mouse cursor. Right?
 >> I never tried that before eCS, docs saying that wouldn't work so I went
 >> to a lot of trouble to always make my apps run FS. :-(
  
 > However, I don't see the need to run FS, for me that is just a 
 > requirement when booting from CD or diskette (no PM).

A small part of my 'a lot of trouble' was actually related to
removing the requirement to run FS, as soon as I found out
that FS wasn't required at all. That was a suprise to me,
despite supporting all possible VIO window sizes. :-)

 > If you have a windowed VIO window, the normal graphic 
 > cursor accurately represents the mouse cursor.
 > (and looks much better anyway)

As mentioned before, in FS the mouse cursor could move while
the mouse cursor doesn't. It took a while before I found out
that MOUSE_MOVING_BN1_DOWN had too be added besides the more
obvious MOUSE_BN1_DOWN (sp?).

 > For an example (and to test the mouse cursor in FS)
 > you can now download DFSee version 7.07 that has
 > mouse capability. It works just fine in a VIO window:
 
 > http://www.dfsee.com/dfsee7xx_os2.zip
 > or
 > http:/www.dfsee.com/dfsee/dfsee7xx_warpin.exe

I'll mention it when I get to see a mouse cursor with that
version, which I don't expect to see.

 > AFAIK, so is the SNAP version (std eCS OEM level).

Std eCS too, here. No (mouse-related) problems with Warp 4
and a S3 Trio driver with the same PC.



---
0
ML
6/30/2005 3:22:35 PM
Sir:

Jan van Wijk wrote:
<snip>
> For an example (and to test the mouse cursor in FS)
> you can now download DFSee version 7.07 that has
> mouse capability. It works just fine in a VIO window:
> 
> 	http://www.dfsee.com/dfsee7xx_os2.zip
> or
> 	http:/www.dfsee.com/dfsee/dfsee7xx_warpin.exe
> 
> 
<snip>
Just to let you know that the Warpin version has old dated documentation 
files within (Dec-Jan last vs the May dates of version 7.xx).  Did not 
check the zip version.
-- 
Bill
Thanks a Million!
0
William
6/30/2005 3:23:15 PM

 > Most likely I should use DosOpen() on "MOUSE$" as 
 > peeking MOUSE.SYS  suggests and use that handle.

Right. I tried it once, but found out not all of the functions
were available as 32-bits, IIRC. One thing about programming I
dislike is re-inventing DosOpen-flag wheels, but I deleted this
little test app of mine.

 > Sure, as a matter of fact, the whole windowing library (source), 
 > including this mouse support will be made available for other 
 > developers in the near future :-)
 
 > (I will present it as an example on the developers conference
 > in Dresden)

:-)



---
0
ML
6/30/2005 3:26:27 PM
On Thu, 30 Jun 2005 15:22:35 UTC, ML <spamgate@hotmai1.com> wrote:

> > If you have a windowed VIO window, the normal graphic 
>  > cursor accurately represents the mouse cursor.
>  > (and looks much better anyway)
>  
> As mentioned before, in FS the mouse cursor could move while
> the mouse cursor doesn't. 

Huh ?

I don't understand that sentence ...

I my experience the mouse-cursor position reported 
by the MouReadEventQue() is an accurate representation
of the graphical cursor that  is visible, in any size windowed
commandline (VIO window).


>It took a while before I found out that MOUSE_MOVING_BN1_DOWN 
>had too be added besides the more obvious MOUSE_BN1_DOWN (sp?).

Yes, and that behaviour is DIFFERENT in windowed 
versus Full-Screen modus.  Caused by using the 'real' 
VIO subsystem versus PM-emulated I guess.

In Windowed you get EITHER the MOUSE_BN1_DOWN if the
mouse is not moved and button-1 is down, OR you get the
MOUSE_MOVING_BN1_DOWN when it IS moved with
that button down. (values 0x04 and 0x02 respectively)

In an FS session, you get either MOUSE_BN1_DOWN 
alone when not moved or MOUSE_BN1_DOWN ored 
with MOUSE_MOVING_BN1_DOWN and MOUSE_MOTION
when it is. (values 0x04 and 0x09 respectively).

I simply fileter out the MOUSE_MOTION (0x01) and test
for all other combinations ...


Regards, JvW 


-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/1/2005 10:15:42 AM
On Thu, 30 Jun 2005 15:23:15 UTC, "William L. Hartzell" <wlhartzell@comcast.net> wrote:
Hi Bill,

> Just to let you know that the Warpin version has old dated documentation 
> files within (Dec-Jan last vs the May dates of version 7.xx).  Did not 
> check the zip version.

Hmm, I just checked, most have accurate timestamps in both (June 28, 2005)
A few are older, but have not had any updates since then.
Not all documentation files are changed in every release ...

Maybe you are confused by last-write versus last access timestamps ? 

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/1/2005 10:17:43 AM
On Thu, 30 Jun 2005 15:10:03 UTC, ML <spamgate@hotmai1.com> wrote:

> Perhaps a candidate for the most stupid remark ever made here, but
> IIRC there was a package called something like RXANSI20.ZIP. That
> used 'classic' ANSI codes with REXX to change colors, e.g. :
>  
>       SAY red_on_white 'Red characters, white background'
>  
> Nothing fancy, I assume it just filled the variable red_on_white
> with the right ANSI consol I/O escape codes.
>  
> IIRC/2 that package also included a mouse function, which IIRC/3
> looked slightly different from Mou* implementations, so then it
> wouldn't be just a 'wrapper'. Does ANSI(.SYS) indeed include
> support for a basic mouse funtion? 

No, just keyboard and screen.

However, it is possible RXANSI used the MOU* functions
to add mouse support.

>If so, that could be 'the'
> other way to get it working properly. No OS/2 PC available
> here at the moment, so I cannot tell if RXANSI20.ZIP (?) works
> properly here now. 

Well, the RXANSI package is nowhere to be found, I checked
hobbes and Googled quite a bit as well ... 

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/1/2005 10:37:35 AM
Sir:

Jan van Wijk wrote:
> On Thu, 30 Jun 2005 15:10:03 UTC, ML <spamgate@hotmai1.com> wrote:
> 
>> Perhaps a candidate for the most stupid remark ever made here, but
>> IIRC there was a package called something like RXANSI20.ZIP. That
>> used 'classic' ANSI codes with REXX to change colors, e.g. :
>>  
>>       SAY red_on_white 'Red characters, white background'
>>  
>> Nothing fancy, I assume it just filled the variable red_on_white
>> with the right ANSI consol I/O escape codes.
>>  
>> IIRC/2 that package also included a mouse function, which IIRC/3
>> looked slightly different from Mou* implementations, so then it
>> wouldn't be just a 'wrapper'. Does ANSI(.SYS) indeed include
>> support for a basic mouse funtion? 
> 
> No, just keyboard and screen.
> 
> However, it is possible RXANSI used the MOU* functions
> to add mouse support.
> 
>> If so, that could be 'the'
>> other way to get it working properly. No OS/2 PC available
>> here at the moment, so I cannot tell if RXANSI20.ZIP (?) works
>> properly here now. 
> 
> Well, the RXANSI package is nowhere to be found, I checked
> hobbes and Googled quite a bit as well ... 
> 
> Regards, JvW
> 
Ask Jeeves has this quote:
REXX Tips & Tricks, Version 2.80

Inf-HTML [About][Toc][Index] 0.9b (c) 1995 Peter Childs
RXANSI - Rexx eXtension for ANSI ($)


Name     RXANSI - Rexx eXtension for ANSI
Version  v1.02, 4/91
Author   Steve Mullarkey
          95 Greenville Drive
          Low Moor, Bardford
          West Yorkshire
          England
          BD12 OPT.
Distrib. Shareware
Type     REXX DLL
Price    _15
Source   BBS
          Name: RXANSI.*

Description from the author:

"RXANSI is a REXX extension for OS/2 1.2 EE and OS/2 1.3 SE. It was
developed due to the lack of power available in REXX to perform screen
I/O."

A highlight of this DLL is the mouse support for REXX textmode programs.

The DLL provides the following functions:

    *  RxAnsiInit()
    *  RxGoTo(x,y)
    *  RxGetChar()
    *  RxGetChars()
    *  RxPutChars(x)
    *  RxLine(x1,y1,x2,y2,n)
    *  RxBox(x1,y1,x2,y2,Fill)
    *  RxHMenu(x1,y1,options)
    *  RxVMenu(x1,y1,options)
    *  RxMode(mode,handle)
    *  RxLineType(V,H)
    *  RxMouse( < ON | OFF > )


Inf-HTML End Run - Successful

-- 
Bill
Thanks a Million!
0
William
7/1/2005 9:21:17 PM
Sir:

Jan van Wijk wrote:
> On Thu, 30 Jun 2005 15:23:15 UTC, "William L. Hartzell" <wlhartzell@comcast.net> wrote:
> Hi Bill,
> 
>> Just to let you know that the Warpin version has old dated documentation 
>> files within (Dec-Jan last vs the May dates of version 7.xx).  Did not 
>> check the zip version.
> 
> Hmm, I just checked, most have accurate timestamps in both (June 28, 2005)
> A few are older, but have not had any updates since then.
> Not all documentation files are changed in every release ...
> 
> Maybe you are confused by last-write versus last access timestamps ? 
> 
> Regards, JvW
> 
I'd assumed that was the case, eg. the documentation had not changed. 
No, only Warpin bitched that the archive had older files than what was 
on my hard drive from Installing an earlier 7.xx (whatever date it was 
comparing which seems to be the date that I installed 7.00).  Also 
noticed that the dfsee.key file now has to be in the bin folder, instead 
of the \os2 folder.
-- 
Bill
Thanks a Million!
0
William
7/1/2005 9:30:21 PM
Hi Bill,

On Fri, 1 Jul 2005 21:21:17 UTC, "William L. Hartzell" <wlhartzell@comcast.net> wrote:

> > Well, the RXANSI package is nowhere to be found, I checked
> > hobbes and Googled quite a bit as well ... 
> > 
> > Regards, JvW
> > 
> Ask Jeeves has this quote:
> REXX Tips & Tricks, Version 2.80
>  
> Inf-HTML [About][Toc][Index] 0.9b (c) 1995 Peter Childs
> RXANSI - Rexx eXtension for ANSI ($)
<snip>  
  
Thanks Bill, I eventually got a copy.
However, since there are no sources, 
it is not of much educational value ...

Looks like a nice package though!

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/2/2005 7:51:14 AM
Hi Bill,

On Fri, 1 Jul 2005 21:30:21 UTC, "William L. Hartzell" <wlhartzell@comcast.net> wrote:

> > Maybe you are confused by last-write versus last access timestamps ? 
> > 
> > Regards, JvW
> > 
> I'd assumed that was the case, eg. the documentation had not changed. 
> No, only Warpin bitched that the archive had older files than what was 
> on my hard drive from Installing an earlier 7.xx (whatever date it was 
> comparing which seems to be the date that I installed 7.00).  

OK, that is a bit strange, I always install it myself so I should have noticed.
I will see if I can touch all of them for the next release just to make sure
problems like that do not occur anymore ...


>Also noticed that the dfsee.key file now has to be in the bin folder, instead 
> of the \os2 folder.

Well, it must be wherever the EXE is (or in the PATH) and in
the WARPIN version I choose to make a few seperate
directories instead of one large one ...

You can also put it somewhere in a tools or other directory
that is in your PATH and keep the DFSee directory clean ... 

Regards, JvW


-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/2/2005 7:55:50 AM
Hi,

being curious I ran exehdr.exe /V against fc.exe and found out that
FC does not make use of MouDrawPtr.
I think it would be a very good idea to contact Brian Harvard (FC's 
author) and find out how he worked around the problem (of lost mouse 
cursor in FS apps).
I googled around and found a few old postings by him that indicated that 
he was fighting with the same problems.
If you do, would you please post the results.

Lars

Jan van Wijk schrieb:
> On Wed, 29 Jun 2005 21:36:37 UTC, spamgate@hotmai1.com (ML) wrote:
>   
> 
>>BTW, a windowed VIO session never had a FS-like mouse cursor. Right?
>>I never tried that before eCS, docs saying that wouldn't work so I went
>>to a lot of trouble to always make my apps run FS. :-(
>> 
> 
> 
> Right, the block-shaped cursor is only displayed in a 
> full-screen session, if at all.
> That is for OS/2 sessions, I remember you could get both displayed 
> (in slightly different positions :-) inside a DOS VDM window.
> 
> 
> However, I don't see the need to run FS, for me that is just a 
> requirement when booting from CD or diskette (no PM).
> 
> If you have a windowed VIO window, the normal graphic 
> cursor accurately represents the mouse cursor.
> (and looks much better anyway)
> 
> For an example (and to test the mouse cursor in FS)
> you can now download DFSee version 7.07 that has
> mouse capability. It works just fine in a VIO window:
> 
> 	http://www.dfsee.com/dfsee7xx_os2.zip
> or
> 	http:/www.dfsee.com/dfsee/dfsee7xx_warpin.exe
> 
> 
> On FS, on most systems it seems hit and miss, but there
> is one (also eCS 1.2) system that sofar ALWAYS displays
> the mouse cursor correctly.
> I have not found the difference yet, the mouse.sys
> and BVH*.DLL files are identical.
> AFAIK, so is the SNAP version (std eCS OEM level).
> 
> Of course the hardware (videocard) is different ...
> 
> Regards, JvW
> 
0
Lars
7/2/2005 10:28:30 AM
 > Name     RXANSI - Rexx eXtension for ANSI
 
Yes, that's the one.

 > Distrib. Shareware
 
My documentation doesn't mention that, but it does mention that the
mouse cursor could remain on the screen if one doesn't CALL RxMouse
'OFF'. That gave me the impression that it could (!) work differently
by using another way of displaying a mouse cursor, e.g. using ANSI.SYS
instead of a(nother) mouse API.

This obviously wouldn't be true if skipping MouseRemovePtr() can show
the same behaviour, and if ANSI.SYS has no mouse support I still don't
know how RXANSI works (without decompiling it, which is not my cup of
tea at all).



---
0
spamgate
7/2/2005 12:37:03 PM
 >> As mentioned before, in FS the mouse cursor could move while
 >> the mouse cursor doesn't. 

 > I don't understand that sentence ...
 
Excuse me. When a FS is 80x25 characters and 800x250 'mickeys', one
can move the mouse cursor a few 'mickeys' without the block-shaped
cursor moving. The mickey mouse cursor moves, but the block-shaped
mouse cursor doesn't. MouReadEventQue() then won't work with just
MOUSE_BN1_DOWN. For a while I thought it was yet another problem.
It isn't.



---
0
spamgate
7/2/2005 12:45:57 PM
 > However, it is possible RXANSI used the MOU* functions
 > to add mouse support.
 
Allright, just learning. And I just learned about EXEHDR's /V switch,
which returns this MOUCALLS.*'s for RXANSI.DLL:

    PTR     2d34  imp MOUCALLS.9
    PTR     2daf  imp MOUCALLS.16
    PTR     2d85  imp MOUCALLS.17
    PTR     2d26  imp MOUCALLS.18
    PTR     2c47  imp MOUCALLS.20
    PTR     2dba  imp MOUCALLS.26

Looks like 16-bit Mou* to me (also consider the age of RXANSI.DLL).



---
0
spamgate
7/2/2005 12:57:43 PM
On Sat, 2 Jul 2005 12:45:57 UTC, spamgate@hotmai1.com (ML) wrote:

> > I don't understand that sentence ...
>  
> Excuse me. When a FS is 80x25 characters and 800x250 'mickeys', one
> can move the mouse cursor a few 'mickeys' without the block-shaped
> cursor moving. The mickey mouse cursor moves, but the block-shaped
> mouse cursor doesn't. MouReadEventQue() then won't work with just
> MOUSE_BN1_DOWN. For a while I thought it was yet another problem.
> It isn't.

Hmm, are you sure ?

I thought about that problem, getting multiple move events for a 1 
character move, but found that it did not happen. I seem to get 
exactly one event with every row/column in the character grid ...

Perhaps it makes a difference if you actually want the pure
movement events too, I filter those (mask 0x7E) because
I only need move info if a button is down (dragging).

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/2/2005 4:12:44 PM
Hi Lars,

On Sat, 2 Jul 2005 10:28:30 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> being curious I ran exehdr.exe /V against fc.exe and found out that
> FC does not make use of MouDrawPtr.

OK, then it is possible he uses DosIOCtl to get to
the mousedriver directly. I have not figured out all the details,
but doing that solves some issues with multi-threading too.

Strange thing is, he DOES use MouRemovePtr()

> I think it would be a very good idea to contact Brian Harvard (FC's 
> author) and find out how he worked around the problem (of lost mouse 
> cursor in FS apps).
> I googled around and found a few old postings by him that indicated that 
> he was fighting with the same problems.
> If you do, would you please post the results.

I will see if I have any current contact info for Brian.
(I have FC registred for OS2 and Windows)

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/2/2005 4:57:11 PM
 >> Excuse me. When a FS is 80x25 characters and 800x250 'mickeys', one
 >> can move the mouse cursor a few 'mickeys' without the block-shaped
 >> cursor moving. The mickey mouse cursor moves, but the block-shaped
 >> mouse cursor doesn't. MouReadEventQue() then won't work with just
 >> MOUSE_BN1_DOWN. For a while I thought it was yet another problem.
 >> It isn't.

 > Hmm, are you sure ?

Assuming FS and a visible mouse cursor, you could add a loop or a
counter to Lars' skeleton app. Run it, keep the visible mouse cursor
at the same position while quickly pressing the mouse button exactly
10 times. Typically I'ld expect to score about 9 out of 10, the other
one probably was a MOUSE_MOVING_BN1_DOWN instead of a MOUSE_BN1_DOWN.
Pressing the mouse button for a longer period of time each time solves
this, as does using both MOUSE_MOVING_BN1_DOWN and MOUSE_BN1_DOWN
instead of just MOUSE_BN1_DOWN. If you don't, it may look like the
mouse responds very slowly because the button has to be pressed for
a rather long time, or it just misses hits. The visible mouse cursor
may also move because it's shifted just 1 'mickey', but that shouldn't
really matter. If that matters, I'ld blame the UI design.

A possible need to distinguish between MOUSE_BN1_DOWN and *_BN1_DOWN
could require another solution than just ignoring the *MOVING* options.
If I want to keep a fast (looking) response to MOUSE_BN1_DOWN, I could
e.g. check how long the button was pressed, or if a D&D operation has
'traveled' a meaningfull distance with a valid destination. If you
don't meet such additional requirements, the user probably intended a
MOUSE_BN1_DOWN instead of another operation, despite MouseReadEventQueue
returning another value.

 > Perhaps it makes a difference if you actually want the pure
 > movement events too, I filter those (mask 0x7E) because
 > I only need move info if a button is down (dragging).

First of all, I'ld make sure that a drag operation cannot happen by
accident with a good UI design (one typically doesn't have 80x25 icons
on the desktop either). An accident could include an unwanted movement
of the underlying 'mickeys' mouse cursor, which also could cause a move
of the block-shaped mouse cursor. Perhaps checking the distance of the
drag operation can distinguish between an intended move and an accident.
Dragging also is delicatly enough to take some time to complete, so that
also could be a possible (additional) check.

Anyway, I cannot think of an operation that cannot be checked, without
ending up with an UI which looks really slow to an user. If possible,
I'ld prefer masks (and a FS UI with limited possibilities) above any
more complicated UI.



---
0
spamgate
7/2/2005 7:36:49 PM
On Sat, 2 Jul 2005 19:36:49 UTC, spamgate@hotmai1.com (ML) wrote:
> Assuming FS and a visible mouse cursor, you could add a loop or a
> counter to Lars' skeleton app. Run it, keep the visible mouse cursor
> at the same position while quickly pressing the mouse button exactly
> 10 times. Typically I'ld expect to score about 9 out of 10, the other
> one probably was a MOUSE_MOVING_BN1_DOWN instead of a MOUSE_BN1_DOWN.

But have you actually DONE that ?

As said, I have a similar solution to what was in Lars skeleton, and in 
my (limited) testing I never get an event when the 'mickey' mouse
cursor moves WITHIN the bcharacter cell boundary ...


> Pressing the mouse button for a longer period of time each time solves
> this, as does using both MOUSE_MOVING_BN1_DOWN and MOUSE_BN1_DOWN
> instead of just MOUSE_BN1_DOWN. 

That is what I do, I test for both (as well as the combination of both)
so I will see the button-down even for sure.

For my own 'dragging' purposes (moving/sizing text-windows) I only need
to know if the mouse position has moved to another character cell.
Checking for the three possible combinations of just MOUSE_BN1_DOWN,
just MOUSE_MOTION_WITH_BN1_DOWN and the combination of these 
two set seems to be a reliable way of detecting that, and does NOT give 
additional false events where the position has not been moved to 
another character cell.

>If you don't, it may look like the mouse responds very slowly because the button has to be pressed for
> a rather long time, or it just misses hits. The visible mouse cursor
> may also move because it's shifted just 1 'mickey', but that shouldn't
> really matter. If that matters, I'ld blame the UI design.
>  
> A possible need to distinguish between MOUSE_BN1_DOWN and *_BN1_DOWN
> could require another solution than just ignoring the *MOVING* options.

I gues you mean *MOTION* here ...

I am not ignoring the *MOTION* options at all, instead I request NOT 
to be informed for mouses movements when NO button is down.
This would be the "MOUSE_MOTION" event (value 0x0001)

> If I want to keep a fast (looking) response to MOUSE_BN1_DOWN, I could
> e.g. check how long the button was pressed, or if a D&D operation has
> 'traveled' a meaningfull distance with a valid destination. If you
> don't meet such additional requirements, the user probably intended a
> MOUSE_BN1_DOWN instead of another operation, despite MouseReadEventQueue
> returning another value.

I don't want to delay a BUTTON_DOWN from the user, so starting
a 'drag' operation (not, not real D&D, this IS text-mode :-) will
always start with a button-down event on the start location ...
  
>  > Perhaps it makes a difference if you actually want the pure
>  > movement events too, I filter those (mask 0x7E) because
>  > I only need move info if a button is down (dragging).
>  
> First of all, I'ld make sure that a drag operation cannot happen by
> accident with a good UI design (one typically doesn't have 80x25 icons
> on the desktop either). An accident could include an unwanted movement
> of the underlying 'mickeys' mouse cursor, which also could cause a move
> of the block-shaped mouse cursor. Perhaps checking the distance of the
> drag operation can distinguish between an intended move and an accident.
> Dragging also is delicatly enough to take some time to complete, so that
> also could be a possible (additional) check.
>  
> Anyway, I cannot think of an operation that cannot be checked, without
> ending up with an UI which looks really slow to an user. If possible,
> I'ld prefer masks (and a FS UI with limited possibilities) above any
> more complicated UI.

Right, that is why I only support a reasonable subset of mouse behaviour
in a full singing and dancing GUI environment in my text-mode library.

The events at the WindowsProcedure level in my library are:

- BUTTON_DOWN events for button 1..3
- BUTTON_UP (meaning ALL buttons are UP, implies end-drag)
- MOUSEMOVE (start drag, or dragging, by capture context)
 
Dragging state (start-drag or already-dragging) is simply determined 
using a mechanism much like the MouseCapture() functionality in PM
or Windows-GUI, where all mouse events are directed to a specific
window while the mouse is being dragged ...


This keeps timing issues and time-consuming tests to a minimum, 
and also allows easy cross-platform implementation.
(I currently support the mouse in DOS, OS2 and Windows)

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/3/2005 10:33:54 AM
 > I have not found the difference yet
 
Is this the (source code of the) package with the properly working
mouse cursor? -> http://hobbes.nmsu.edu/pub/new/fm2-3_03-src.zip



---
0
spamgate
7/5/2005 7:05:50 PM
In <OotyClQNAReY090yn@hotmai1.com>, on 07/05/2005
   at 09:05 PM, spamgate@hotmai1.com (ML) said:

>Is this the (source code of the) package with the properly working mouse
>cursor? -> http://hobbes.nmsu.edu/pub/new/fm2-3_03-src.zip

This source code decent resource, if I don't say so myself.  However,
unlike dfsee, fm/2 is a pure GUI app.

Regards,

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
7/5/2005 7:48:19 PM
On Tue, 5 Jul 2005 19:05:50 UTC, spamgate@hotmai1.com (ML) wrote:

> > I have not found the difference yet
>  
> Is this the (source code of the) package with the properly working
> mouse cursor? -> http://hobbes.nmsu.edu/pub/new/fm2-3_03-src.zip
  
No FM/2 is a GUI application, my stuff is textmode (VIO)

The one I mentioned was FC/2 (File Commander, a Norton Commander clone)

BTW:
I have the cursor show/hide working the way I 
want now, using DosDevIOCtl() calls to do it.
But still, it only works reliable on SOME systems, and 
on most systems it will work every once in a while.

Could be some kind of (missing) initialisation issue ...

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/5/2005 8:58:45 PM
Sir:

Jan van Wijk wrote:
> On Tue, 5 Jul 2005 19:05:50 UTC, spamgate@hotmai1.com (ML) wrote:
> 
> 
>>>I have not found the difference yet
>>
>> 
>>Is this the (source code of the) package with the properly working
>>mouse cursor? -> http://hobbes.nmsu.edu/pub/new/fm2-3_03-src.zip
> 
>   
> No FM/2 is a GUI application, my stuff is textmode (VIO)
> 
> The one I mentioned was FC/2 (File Commander, a Norton Commander clone)
> 
> BTW:
> I have the cursor show/hide working the way I 
> want now, using DosDevIOCtl() calls to do it.
> But still, it only works reliable on SOME systems, and 
> on most systems it will work every once in a while.
> 
> Could be some kind of (missing) initialisation issue ...
> 
> Regards, JvW
> 
I may be off base, but have you tried a pure MCP1 system?  I know that 
IBM has messed up the mouse sub system by integrating the trackpoint 
driver into it.  Open up a recent Smouse fixpack to see what dll, etc 
were changed.  Maybe you can work around this bug if you know what API 
were changed by avoiding them?  I know that I had to back level several 
dlls, & driver to MCP1 level to keep my mouse working.  Even the latest 
Smouse fixpack has problems with my system, though it is better than 
previous versions of Smouse.  So for MCP fixpack three and later, I keep 
these files available so I can back level.  Because of the Dlls, even 
using Amouse does not avoid the problems.  My peeve, so if it is not 
relevant, disregard.
-- 
Bill
Thanks a Million!
0
William
7/6/2005 5:32:21 AM
To me DosDevIOCtl has been equally unreliable. I have played around with 
MouSetDevStatus, explicitely clearing the "don't call pointer draw 
device driver" flag. That didn't help either.
I think the best idea is to contact Brian Harvard (brian.harvard AT 
gmail.com).

Lars

Jan van Wijk schrieb:
> On Tue, 5 Jul 2005 19:05:50 UTC, spamgate@hotmai1.com (ML) wrote:
> 
> 
>>>I have not found the difference yet
>>
>> 
>>Is this the (source code of the) package with the properly working
>>mouse cursor? -> http://hobbes.nmsu.edu/pub/new/fm2-3_03-src.zip
> 
>   
> No FM/2 is a GUI application, my stuff is textmode (VIO)
> 
> The one I mentioned was FC/2 (File Commander, a Norton Commander clone)
> 
> BTW:
> I have the cursor show/hide working the way I 
> want now, using DosDevIOCtl() calls to do it.
> But still, it only works reliable on SOME systems, and 
> on most systems it will work every once in a while.
> 
> Could be some kind of (missing) initialisation issue ...
> 
> Regards, JvW
> 
0
Lars
7/6/2005 10:04:49 PM
Hi Lars,

On Wed, 6 Jul 2005 22:04:49 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> To me DosDevIOCtl has been equally unreliable. 

In my tests it is NOT less reliable than MouDrawPtr()
they probably end up using the same code ;-)

I think the problem is with initializing the MOU subsystem somehow.


>I have played around with  MouSetDevStatus, explicitely clearing 
>the "don't call pointer draw  device driver" flag. That didn't help either.

I have not experimented much with that, but I might.


One interesting observation is that replacing the MOUSE.SYS 
driver on my thinkpad, which was the standard eCS 1.2 one,
by a real old one (2001) that I had saved somewhere.

That got the mouse-cursor working just fine in full-screen sessions!
(but broke mouse wheel support :-)

I think there is a problem with later mouse-driver versions that
cause the FS-cursor visibility problems:
 - on most, but not all hardware (several systems work fine)
 - with the standard documented MOU susbsystem initialization
   (since some apps seem to get it right all the time)

> I think the best idea is to contact Brian Harvard (brian.harvard AT 
> gmail.com).

I may try that, thanks.

Regards, JvW
 

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/7/2005 5:44:44 AM
Hi Jan,

at least on my system I have narrowed down the problem to be this:
1.) first call to a FS app with mouse support, everything is OK and 
mouse pointer draws just fine, no matter if you use DosDevIOCtl or 
MouDrawPtr
2.) start of a presentation manager application
3.) second call to that FS app, and the mouse won't show up
4.) stop of the presentation manager app started in 2.)
5.) wait a while (I couldn't tell you how long)
6.) third call to the FS app and the mouse pointer will draw alright

So, if people say it ALWAYS works on their system, they just might have 
not gone through a sequence where it fails.

Lars

Jan van Wijk schrieb:
> Hi Lars,
> 
> On Wed, 6 Jul 2005 22:04:49 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
> 
> 
>>To me DosDevIOCtl has been equally unreliable. 
> 
> 
> In my tests it is NOT less reliable than MouDrawPtr()
> they probably end up using the same code ;-)
> 
> I think the problem is with initializing the MOU subsystem somehow.
0
Lars
7/7/2005 5:21:08 PM
[A complimentary Cc of this posting was sent to
Lars Erdmann 
<lars.erdmann@arcor.de>], who wrote in article <42cd647f$0$10805$9b4e6d93@newsread4.arcor-online.net>:
> 1.) first call to a FS app with mouse support, everything is OK and 
> mouse pointer draws just fine, no matter if you use DosDevIOCtl or 
> MouDrawPtr

Not here.  Mouse cursor is not visible here (ncurses application, so
it uses Mou*() calls).  If I move the mouse a lot with a pressed
button, then sometimes a very short trace (!) remains.

> 2.) start of a presentation manager application

I do not follow it here.  Could you use e.exe as an example?  Or is
not WPS running on your system?

Thanks,
Ilya
0
Ilya
7/7/2005 10:39:13 PM
 >> Assuming FS and a visible mouse cursor, you could add a loop or a
 >> counter to Lars' skeleton app. Run it, keep the visible mouse cursor
 >> at the same position while quickly pressing the mouse button exactly
 >> 10 times. Typically I'ld expect to score about 9 out of 10, the other
 >> one probably was a MOUSE_MOVING_BN1_DOWN instead of a MOUSE_BN1_DOWN.
 
 > But have you actually DONE that ?

Yes. 

 > As said, I have a similar solution to what was in Lars skeleton,
 > and in my (limited) testing I never get an event when the 'mickey'
 > mouse cursor moves WITHIN the bcharacter cell boundary ...

Have you actually done the test above? 10 times a MOUSE_BN1_DOWN
in a loop. Keep the FS mouse cursor at the same spot but don't
glue the mouse to your mousepad. Hold it normally but quite steady.
Press the mouse button 10 times as fast as you can without moving
the FS mouse cursor, and you may discover too that MOUSE_BN1_DOWN
just scored 9 out of 10 (it could depend on the wait option in use).

If you don't experience this problem, it could be that you are
too slow. That is, you press the mouse button for too long. 
  
 >> A possible need to distinguish between MOUSE_BN1_DOWN and *_BN1_DOWN
 >> could require another solution than just ignoring the *MOVING* options.
 
 > I gues you mean *MOTION* here ...

That's very likely.

 > I don't want to delay a BUTTON_DOWN from the user

I ment checking the time a D&D (or another complicated operation)
took. One cannot complete an intented D&D operation within about
0.3 second. It should also take longer than the time it takes to
recognize a double click. Pressing and releasing the mouse button
takes some time, moving the mouse cursor takes some time and
aiming too. OTOH I could complete an unintented 'mickey' D&D
within 0.2 second.

 > not real D&D, this IS text-mode :-)

Well, in a GUI world we're just pretending things are object too.
Anyway, in a text-mode app I probably wouldn't expect nor support
true D&D. It's not straight-forward too.

 > Right, that is why I only support a reasonable subset of mouse
 > behaviour

That sounds like a good choice to me.

BTW earlier I mentioned replacing MOUSE.SYS with an old copy
solves some mouse cursor visibility problems. IIRC it broke as
of a must-have Warp 3 NL fixpack. Perhaps checking the APAR's
(sp?) gives a clue, and again IIRC this solution was mentioned
by Ruud Uphoff (@dosgg.nl?). One could also contact him to
narrow the problem down, but I don't know if he has a sulution
other than downgrading MOUSE.SYS, and obviously I don't know if
he even remembers meeting this problem at all.




---
0
ML
7/15/2005 12:02:58 PM
On Fri, 15 Jul 2005 12:02:58 UTC, ML <spamgate@hotmai1.com> wrote:

> >> Assuming FS and a visible mouse cursor, you could add a loop or a
>  >> counter to Lars' skeleton app. Run it, keep the visible mouse cursor
>  >> at the same position while quickly pressing the mouse button exactly
>  >> 10 times. Typically I'ld expect to score about 9 out of 10, the other
>  >> one probably was a MOUSE_MOVING_BN1_DOWN instead of a MOUSE_BN1_DOWN.
>  
>  > But have you actually DONE that ?
>  
> Yes. 
>  
>  > As said, I have a similar solution to what was in Lars skeleton,
>  > and in my (limited) testing I never get an event when the 'mickey'
>  > mouse cursor moves WITHIN the bcharacter cell boundary ...
>  
> Have you actually done the test above? 10 times a MOUSE_BN1_DOWN
> in a loop. Keep the FS mouse cursor at the same spot but don't
> glue the mouse to your mousepad. Hold it normally but quite steady.
> Press the mouse button 10 times as fast as you can without moving
> the FS mouse cursor, and you may discover too that MOUSE_BN1_DOWN
> just scored 9 out of 10 (it could depend on the wait option in use).
>  
> If you don't experience this problem, it could be that you are
> too slow. That is, you press the mouse button for too long. 

Well, I guess THAT could happen, getting the other message intead of
the "non-motion" variant of it. I guess I misunderstood your testcase.

However, in my situation I am not really interested in the difference,
since I do not support double-clicks or D&D anyway ...
   
<snip>  
> BTW earlier I mentioned replacing MOUSE.SYS with an old copy
> solves some mouse cursor visibility problems. 


I tried a few, and allthough it seemed to influence the odds on 
it working correctly a bit, it was no 100% fix for the problem.

I am pretty sure it is fixable using a different order of initialisation
or different parameters, since File Commander gets it right
ALL the time. (And I checked the MOU* calls it is using) 

Will try to get in touch with Brian Harvard who wrote that ...

It is NOT a major problem anyway, it happens on SOME full-screen 
scanarios only, and you can work very well without the mouse.

It is mainly on a graphical desktop that using the mouse 
seems more natural, and it works fine there.

Regards, JvW

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
7/16/2005 7:50:31 PM
Quoting "Jan van Wijk" <jvw.no.spam@dfsee.com>,
  Re: Mouse cursor in OS2 full-screen sessions (16 Jul 2005 19:50:31 GMT):

>On Fri, 15 Jul 2005 12:02:58 UTC, ML <spamgate@hotmai1.com> wrote:

<snip>  

>> BTW earlier I mentioned replacing MOUSE.SYS with an old copy
>> solves some mouse cursor visibility problems. 

>I tried a few, and allthough it seemed to influence the odds on  it
>working correctly a bit, it was no 100% fix for the problem.

<snip>

>It is NOT a major problem anyway, it happens on SOME full-screen 
>scanarios only, and you can work very well without the mouse.

<snip>

(Walt's long delayed comment):

Well, maybe not a problem for your program, but this intermittently
invisible fullscreen vio mouse pointer really is a severe bug for a
lot of programs.  It's pretty hard to take full advantage of mouse
enabled programs (e.g., the JED editor, Lynx browser, etc) if you
can't see the darn pointer.  And full-screen mode is *mandatory* if
you want to use compressed screens (mode co80,25/50/60, mode
co132,25/50/60), which do work with SNAP graphics v3.  I've spent
quite a bit of time trying to find any patterns behind the vanishing
cursor, and for what it's worth, I think it probably *is* the mouse
driver.  My observations are listed below in case they might be
useful to anyone, but the main finding is that switching to an old
driver without mouse wheel support fixed the problem for me.

With an old mouse driver that does *not* enable the wheel, namely
mouse.sys from OS/2 Warp 3 Fixpak 39, on my system, 100% of os/2
full-screen sessions support a visible pointer for mouse-enabled
programs.  It doesn't matter what other programs or windows are open.
It seems to work, every time without fail.

With the IBM scrollpoint mouse driver, only 20-50% of os/2 full-screen
sessions support a pointer for mouse-enabled programs.  If a given
session comes up with support, then 100% of the time a mouse-enabled
program started in that particular session has its visible pointer.
But if the session came up without support, then 100% of the time a
mouse-enabled program started in that particular session has an
invisible pointer.

I also tried XMOUSE v5 (Dec. 27, 2001) by Martin Lafaix from
http://lafaix.online.fr/tmp/xmouse.zip.  It exhibits the same behavior
as the scrollpoint mouse.  If you try this, don't draw conclusions too
quickly: the first time I tried it, the first 10 full screen sessions I
opened all had mouse support.  But it turned out to be hugely dependent
on what else is running and wildly unpredictable.  (It might make a
good random number generator.)

I suspect the problem is a timing bug, such that something in the low
level mouse support doesn't always get initialized quite right when an
OS/2 full screen session is opened.  It seems to be very dependent on
what else is running.  Opening or closing os/2 window sessions, a
GSView (Ghostscript) session, or a WarpVision session can make a string
of newly opened OS/2 full screen sessions come up with mouse pointer
support, or without it, in no predictable fashion.  Maybe it's because
CPUs are faster than they used to be?  (Mine is a 1.2GHz Celeron
running Warp 3 fixpak 39). Whatever the cause, this invisible pointer
in full screen issue is not new. I found these references:

 * APAR=PJ24093: Mouse cursor Not Shown in OS/2 Full-Screen session
 using KEdit.  I couldn't find an actual technical description, just
 the summary claiming it was fixed.  Would be nice to find more info on
 this APAR.

 * Brian Havard thread, FP22/26 kills fullscreen mouse pointer (Jan 1, 
 1997)

 * Mike Dickson thread, Cursor Problem with Full Screen VIO (Jan. 21,
 1997).

 * Andreas Grosche thread, No mouse pointer in fullscreen OS/2 sessions
 (Mar. 5, 2000).

 * Jan van Wijk thread, Mouse cursor in OS/2 full-screen sessions (June
 27, 2005)(This thread).

Alas, no one has found a solution.  For now, my workaround is to go
back to the old-fashioned no-wheel mouse driver from Warp 3 fixpak39.
But I do miss the wheel.  If anyone ever figures out how to fix this
bug, *please* post the info.  Thanks.

-- 
Walt (To email, remove .invalid from address, or visit
personal home page http://www.w-gregg.juneau.ak.us.)

0
Nospam05j
10/20/2005 5:18:14 AM
[A complimentary Cc of this posting was sent to

<Nospam05j@w-gregg.juneau.ak.us.invalid>], who wrote in article <43572ced$1$jnyg$mr2ice@news.gci.net>:
> can't see the darn pointer.  And full-screen mode is *mandatory* if
> you want to use compressed screens (mode co80,25/50/60, mode
> co132,25/50/60), which do work with SNAP graphics v3.

I'm not clear what you mean here.  I'm running lynx in
  mode 100,60
in a windowed VIO all the time...  Here 60*100 < 8192.

> I've spent quite a bit of time trying to find any patterns behind
> the vanishing cursor, and for what it's worth, I think it probably
> *is* the mouse driver.

Did anybody succeed in contacting Brian (or running FC under a tracing
utility)?  I think FC has no such problem, so there may be a
workaround (but maybe I just do not run it FS often enough...).

Hope this helps,
Ilya
0
Ilya
10/20/2005 12:53:59 PM
"Ilya Zakharevich" <nospam-abuse@ilyaz.org> schrieb im Newsbeitrag 
news:dj8417$gm9$1@agate.berkeley.edu...
> [A complimentary Cc of this posting was sent to
>
> <Nospam05j@w-gregg.juneau.ak.us.invalid>], who wrote in article 
> <43572ced$1$jnyg$mr2ice@news.gci.net>:
>> can't see the darn pointer.  And full-screen mode is *mandatory* if
>> you want to use compressed screens (mode co80,25/50/60, mode
>> co132,25/50/60), which do work with SNAP graphics v3.
>
> I'm not clear what you mean here.  I'm running lynx in
>  mode 100,60
> in a windowed VIO all the time...  Here 60*100 < 8192.

Yes but that doesn't help here as he was talking about FULLSCREEN (the 
"real" text modes of graphic cards) and NOT windowed VIO.

>
>> I've spent quite a bit of time trying to find any patterns behind
>> the vanishing cursor, and for what it's worth, I think it probably
>> *is* the mouse driver.
>
> Did anybody succeed in contacting Brian (or running FC under a tracing
> utility)?  I think FC has no such problem, so there may be a
> workaround (but maybe I just do not run it FS often enough...).

That's what I think, Brian found a workaround. Possibly he is running a 
mouse handling thread that reads the mouse position and updates the mouse 
cursor itself ('XOR'ing the character under the invisible mouse cursor with 
the mouse cursor mask).

Lars 


0
Lars
10/20/2005 4:55:36 PM
 > Possibly he is running a mouse handling thread that reads the
 > mouse position and updates the mouse cursor itself ('XOR'ing
 > the character under the invisible mouse cursor with the mouse
 > cursor mask).

Not being a programmer, so I could have used the wrong tools, but
once I decided to reposition the real mouse myself in an attempt
to emulate borders. Like "if (x<10) {x=10; MouDrawPtr();}". That
looked very ugly, especially with fast movement of the real mouse
cursor hitting the virtual border.

Your XOR'ing isn't the same, but I'ld expect it to end up looking
ugly too. Maybe one can detect such a solution by racing the mouse
cursor across the screen, and pay attention to the fluent movements
of the displayed mouse cursor? I'ld expect it will look notably
different from the real thing.

Again not being a programmer, but IMSR it seems to be broken
since a certain, rather early Warp 3 fixpack. Could looking at
the MOUSE.SYS-code give a usefull clue, or is that too
complicated (even for an expert)? 



---
0
ML
10/20/2005 5:22:07 PM
[A complimentary Cc of this posting was sent to
Lars Erdmann
<lars.erdmann@arcor.de>], who wrote in article <4357cc07$0$12667$9b4e6d93@newsread4.arcor-online.net>:
> >> can't see the darn pointer.  And full-screen mode is *mandatory* if
> >> you want to use compressed screens (mode co80,25/50/60, mode
> >> co132,25/50/60), which do work with SNAP graphics v3.
> >
> > I'm not clear what you mean here.  I'm running lynx in
> >  mode 100,60
> > in a windowed VIO all the time...  Here 60*100 < 8192.
> 
> Yes but that doesn't help here as he was talking about FULLSCREEN (the 
> "real" text modes of graphic cards) and NOT windowed VIO.

He was talking about something being "mandatory".  I still have no
idea what this was supposed to mean...

Hope this helps,
Ilya
0
Ilya
10/20/2005 9:53:18 PM
ML schrieb:
>  > Possibly he is running a mouse handling thread that reads the
>  > mouse position and updates the mouse cursor itself ('XOR'ing
>  > the character under the invisible mouse cursor with the mouse
>  > cursor mask).
> 
> Not being a programmer, so I could have used the wrong tools, but
> once I decided to reposition the real mouse myself in an attempt
> to emulate borders. Like "if (x<10) {x=10; MouDrawPtr();}". That
> looked very ugly, especially with fast movement of the real mouse
> cursor hitting the virtual border.

MouDrawPtr is not meant to be used that way. You call MouDrawPtr exactly 
once in your application. For what you have been trying to achieve:
1.) set up a mouse thread that blocks for mouse events by using 
MouReadEventQueue
2.) When MouReadEventQueue unblocks, check row and column position
3.) Then : if (row < minrow) row = minrow; if (row > maxrow) row = maxrow;
            if (col < mincol) col = mincol; if (col > maxcol) col = maxcol;
4.) Then you'd use MouSetPtrPos to set the new mouse position.

Now, this is the problem, you could end up with no visible effect (when 
the cursor is not showing up, it's not showing up).
In that case, you would
5.) use len=sizeof(USHORT);VioReadCellStr(&char,&len,row,col,0) to read 
the character and display attribute at that position
6.) apply a mouse mask character to the character and display attribute 
you have just written
7.) use len=sizeof(USHORT);VioWrtCellStr(&char,len,row,col,0) to write 
the manipulated character/character attribute back to the screen

> Your XOR'ing isn't the same, but I'ld expect it to end up looking
> ugly too. Maybe one can detect such a solution by racing the mouse
> cursor across the screen, and pay attention to the fluent movements
> of the displayed mouse cursor? I'ld expect it will look notably
> different from the real thing.

The "real" thing does exactly that, it applies a mouse cursor mask to 
the underlying character. You can let the device driver do the "real" 
thing (obviously the most convenient if it there wasn't broken mouse 
drivers) or you can elect to do it yourself as described.
You can toggle that behaviour through a call to MouSetDevStatus 
setting/resetting the appropriate flag.

> 
> Again not being a programmer, but IMSR it seems to be broken
> since a certain, rather early Warp 3 fixpack. Could looking at
> the MOUSE.SYS-code give a usefull clue, or is that too
> complicated (even for an expert)? 

It's not exactly easy, especially because MOUSE.SYS is entirely written 
in Assembler.
In source file "ioset.asm" for MOUSE.SYS there is a routine IOMW_DP 
(Performs the Mouse IOCtl function 57h, reset a session's collision area 
and draw the pointer, being the IOCTL equivalent to 
MouDrawPtr,MouRemovePtr) that seems to be a good candidate for a start, 
so if someone wants to have a look ...

P.S.: At about the same place, I found an interesting IOCTL:
Category 07h,Function 6Ch: "Set the mouse's current constrained region" 
with the following datapacket (as a C structure, no parameter packet):

typedef struct _CONSTRAINRGN
{
   USHORT x0;
   USHORT y0;
   USHORT x1;
   USHORT y1;
} CONSTRAINRGN,*PCONSTRAINRGN;

which sets up a constrained region from x0,y0 to x1,y1 (just as you 
tried above). That IOCTL will make sure to move the mouse cursor into 
the defined constrained region. Maybe that will force the mouse pointer 
to display correctly ...

P.P.S: And yet another undocumented one that could help:
Category 07h,Function 5Eh "GRADD - to register/deregister the task time 
only pointer draw" with the following parameter packet (no data packet):

typedef struct _TSKTIME
{
    ULONG fTaskPtr;
} TSKTIME, *PTSKTIME;

Obviously, this is fTaskPtr = 1 for registering and fTaskPtr = 0 for 
deregistering.

Looking at the pointer draw code in file "util1.asm","DrawPointer" 
function, I would try and set fTaskPtr=0 once on program start as that 
should force a call to the draw function of the POINTER$ device driver 
(POINTDD.SYS, which does the actual mouse pointer drawing).

Maybe I should give it a try ...


Lars
0
Lars
10/20/2005 10:07:02 PM
[A complimentary Cc of this posting was sent to
Lars Erdmann 
<lars.erdmann@arcor.de>], who wrote in article <43581cc8$0$12656$9b4e6d93@newsread4.arcor-online.net>:
> Would anyone having probs with the mouse cursor in fullscreen sessions
> be so kind to run the prog and see if the mouse cursor appears
> correctly.

It does.  I did not retry it *without* IoCtl(0x5e) yet, but lynx does
not show mouse in FS mode.

> By the way: you stop the test program by hitting the 2. mouse button.

BTW: the second mouse button is one which is usually on right (for
those who forgot about this ;-).

Millions of thanks,
Ilya
0
Ilya
10/21/2005 5:23:10 AM
 >> run the prog and see if the mouse cursor appears correctly.

This prog probably did't make it to both of my newsservers.
Repost, please?



---
0
ML
10/21/2005 1:48:07 PM
Ilya Zakharevich schrieb:
> [A complimentary Cc of this posting was sent to
> Lars Erdmann 
> <lars.erdmann@arcor.de>], who wrote in article <43581cc8$0$12656$9b4e6d93@newsread4.arcor-online.net>:
> 
>>Would anyone having probs with the mouse cursor in fullscreen sessions
>>be so kind to run the prog and see if the mouse cursor appears
>>correctly.
> 
> 
> It does.  I did not retry it *without* IoCtl(0x5e) yet, but lynx does
> not show mouse in FS mode.

I am not sure if I understand your answer. The test prog will not cure 
any other application (session, to be precise).
But, if the test prog runs OK every single time it is called no matter 
how often, or what other sessions (DOS windowed, DOS Fullscreen, OS/2 
windowed, OS/2 fullscreen, PM) have been started and/or stopped in 
between two invocations, then I can say that I likely have found the 
flaw in the mouse driver (MOUSE.SYS) and will therefore be able to fix it.

A bit of background: it seems to be some uninitialized variable in the 
"Screen Group Control Block", basically a memory structure that is set 
up per session to control the drawing to the screen.
That's also the reason why the fault is entirely arbitrary, if that 
variable has, by mere chance, the value 0, then the mouse cursor will 
display correctly, if not, the mouse cursor will not show.
And that variable has only been introduced when the display driver model 
has been changed to the GRADD architecture (according to the source code 
comments). That would explain why the error only shows up in more recent 
mouse drivers.

Lars
0
Lars
10/21/2005 5:41:11 PM
[A complimentary Cc of this posting was sent to
Lars Erdmann 
<lars.erdmann@arcor.de>], who wrote in article <43592834$0$23941$9b4e6d93@newsread2.arcor-online.net>:
> Ilya Zakharevich schrieb:
> > [A complimentary Cc of this posting was sent to
> > Lars Erdmann 
> > <lars.erdmann@arcor.de>], who wrote in article <43581cc8$0$12656$9b4e6d93@newsread4.arcor-online.net>:
> > 
> >>Would anyone having probs with the mouse cursor in fullscreen sessions
> >>be so kind to run the prog and see if the mouse cursor appears
> >>correctly.
> > 
> > 
> > It does.  I did not retry it *without* IoCtl(0x5e) yet, but lynx does
> > not show mouse in FS mode.

> I am not sure if I understand your answer.

[No wonder; I immediately wanted to clarify it, but also wanted a more
conclusive testing first.]  This meant:

 a) On my system, there IS a problem with FS VIO mouse pointer (e.g.,
    lynx does not show the pointer);

 b) On my system, your program shows teh FS VIO mouse pointer OK.

Unfortunately, it looks like the whole testing is red herring.

Here are the results of more extensive testing:

--- ./mouse.cpp-ini	Thu Oct 20 22:22:24 2005
+++ ./mouse.cpp	Fri Oct 21 13:58:44 2005
@@ -2,8 +2,13 @@
 #define INCL_DOSDEVIOCTL
 #include <os2.h>
 #include <stdio.h>
+#include <stdlib.h>
 #include <string.h>
 
+#ifndef APIRET16
+#  define APIRET16 APIRET
+#endif
+
 int main(int argc,char *argv[])
 {
     CHAR buf[256];
@@ -13,12 +18,17 @@ int main(int argc,char *argv[])
     HMOU hmou=NULLHANDLE;
     USHORT fWait;
     APIRET16 rc;
+    int todo = 3;
+
+    if (argc > 1)
+	todo = atoi(argv[1]);
 
     rc = MouOpen(NULL,&hmou);
+    if (todo)
     rc = MouSetPtrPos(&mouplPosition,hmou);
     rc = MouDrawPtr(hmou);
 
-    {
+    if (todo > 1) {
         HFILE hMouse;
         APIRET rc;
         ULONG ulAction;
@@ -35,6 +45,7 @@ int main(int argc,char *argv[])
                         NULL
                     );
 
+	if (todo > 2)
         rc = DosDevIOCtl(
                         hMouse,
                         IOCTL_POINTINGDEVICE,


  a) Start FC in FS; it shows the cursor.

  b) Start Lynx inside FC; no cursor visible.

  c) Exit Lynx, returning back to FC; no cursor visible.

  d) start (my modified) mouse.exe inside FC; cursor visible.

  e) click mouse-2, returning back to FC; cursor visible.

So far wonderful.  Unfortunately, repeating from (b) now would never
show the cursor.  No combination of

  lynx
  mouse
  mouse 0
  mouse 1
  mouse 2
  mouse 3

would show cursor again in this session.  Moreover, when used
standalone, all of

  mouse
  mouse 0
  mouse 1
  mouse 2
  mouse 3

show the cursor.  So my initial testing actually shows nothing.

Sigh,
Ilya
0
Ilya
10/21/2005 9:15:36 PM
I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
is willing to test it on their system.

Lars
0
Lars
10/21/2005 11:41:45 PM
Sir:

Lars Erdmann wrote:
> I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
> is willing to test it on their system.
> 
What is the bldlevel of mouse.sys before you modified?  Any chance of 
you doing a fix.pat file?

-- 
Bill
Thanks a Million!
0
William
10/22/2005 12:41:40 AM
I can only tell you that much:
I used the last publicly available DDK source code.
Unfortunately, there is no indication neither in the source code nor 
anywhere else in the DDK that would tell you:

1.) if the source code is even retail/bugfree (to the extent known) or 
only experimental
2.) if the source files match a revision for a release
3.) to what bldlevel version the source code matches
4.) what file revisions make up the released bldlevel versions

So no, there is no way to patch an existing driver. Even if I knew, the 
patch tool wouldn't work because it only allows changes that DO NOT 
change the file size in any way.
But if you introduce changes in the sources, that certainly leads to a 
change of the executable's/driver's length.
In lack of better knowledge, I entitled my compilation to be of 
buildlevel 10.69 (with vendor ERDMANN so everybody knows it's not the 
original IBM driver) where 10.69 corresponds to the version delivered 
with Warp4, Fixpak 16.
At least the file sizes are about the same.

Lars


William L. Hartzell schrieb:
> Sir:
> 
> Lars Erdmann wrote:
> 
>> I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
>> is willing to test it on their system.
>>
> What is the bldlevel of mouse.sys before you modified?  Any chance of 
> you doing a fix.pat file?
> 
0
Lars
10/22/2005 1:42:13 PM
On Fri, 21 Oct 2005 23:41:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> 
wrote:

> I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
> is willing to test it on their system.

Could you please contact Mr. Breining http://www.nbsoftware.de
and discuss the problem with him ?


-- 
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address

0
Ruediger
10/22/2005 2:25:28 PM
Ruediger Ihle schrieb:
> On Fri, 21 Oct 2005 23:41:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> 
> wrote:
> 
> 
>>I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
>>is willing to test it on their system.
> 
> 
> Could you please contact Mr. Breining http://www.nbsoftware.de
> and discuss the problem with him ?
> 
> 
I already did as I am keen of getting it into their amouse.sys as well :-)

Lars
0
Lars
10/22/2005 2:58:29 PM
Quoting Lars Erdmann <lars.erdmann@arcor.de>,
  Re: Mouse cursor in OS2 full-screen sessions - new build of mouse.sys (Sat, 22 Oct 2005 16:58:29 +0200):


>Ruediger Ihle schrieb:
>> On Fri, 21 Oct 2005 23:41:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> 
>> wrote:
>> 
>> 
>>>I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
>>>is willing to test it on their system.
>> 
>> 
>> Could you please contact Mr. Breining http://www.nbsoftware.de
>> and discuss the problem with him ?
>> 
>> 
>I already did as I am keen of getting it into their amouse.sys as well
>:-)

>Lars

As a non-programer, much of the discussion here is over my head, but
if I understand correctly that there is an experimental mouse.sys with
a possible fix in it, I'm sure willing to try it.  But there don't seem
to be any pointers to the actual binary, at least, in the messages that
have shown up here so far.

Regarding my earlier post about it being mandatory to use full screen to use
the compressed modes, what I meant is that selecting mode co132 in a window
doesn't actually change the font at all here. It just gives a horizontal scroll
bar until I muck with the window fonts and size, which is a real pain.  While
in fullscreen, mode co132 actually changes to a true 132 column font that
fits on screen, no muss, no fuss, every time.  Which is why a scrolling mouse
driver with an unreliable fullscreen pointer isn't usable, from my point of
view.  The plain mouse driver pointer works fine for me in fullscreen.  (One
exception I guess I better disclose is that when I tried my copy of Lynx with
the mouse enabled, it often started with the pointer 'frozen' in the middle of
the screen, and other times vanished after a few screens.  But I'm pretty
sure that's in Lynx, nothing else behaves this way.  And lynx works just fine
without a mouse.)


-- 
Walt (To email, remove .invalid from address, or visit
personal home page http://www.w-gregg.juneau.ak.us.)

0
Nospam05j
10/23/2005 8:18:09 AM
[A complimentary Cc of this posting was sent to

<Nospam05j@w-gregg.juneau.ak.us.invalid>], who wrote in article <435b4e7c$1$jnyg$mr2ice@news.gci.net>:
> Regarding my earlier post about it being mandatory to use full screen to use
> the compressed modes, what I meant is that selecting mode co132 in a window
> doesn't actually change the font at all here. It just gives a horizontal scroll
> bar until I muck with the window fonts and size, which is a real
pain.

Expand the window size using mouse.  Hold Shift for the size to persist.

Hope this helps,
Ilya
0
Ilya
10/23/2005 6:05:55 PM
Hi Lars,

On Fri, 21 Oct 2005 23:41:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
> is willing to test it on their system.
  
I sure would (since I started this thread this year :-)
Would be great if you actually found the real problem ...

Do you have it for download somewhere ?

Else you could send it to:

	jvw AT dfsee DOT com

TIA, Jan van Wijk 

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
10/24/2005 12:59:37 PM
Jan van Wijk schrieb:
> Hi Lars,
> 
> On Fri, 21 Oct 2005 23:41:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
> 
> 
>>I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
>>is willing to test it on their system.
> 
>   
> I sure would (since I started this thread this year :-)
> Would be great if you actually found the real problem ...
> 
> Do you have it for download somewhere ?
> 
> Else you could send it to:
> 
> 	jvw AT dfsee DOT com
> 
> TIA, Jan van Wijk 
> 
Find it here in the newsgroup, attached to my email from 23.10.2005.
Please do not distribute or upload anywhere. It's experimental only.

Lars
0
Lars
10/24/2005 5:36:16 PM
On Mon, 24 Oct 2005 17:36:16 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
Hello Lars,

> > Else you could send it to:
> > 
> >         jvw AT dfsee DOT com
> > 
> > TIA, Jan van Wijk 
> > 
> Find it here in the newsgroup, attached to my email from 23.10.2005.

I don't see any post from you on the 23rd, just 20, 21, 22 and 24 ...

Further I do not see any way to see/detach attachements 
here in ProNews, allthough that may become clear as 
soon as I see a message with an attachement :-)

The Help does not seem to function at all ...

> Please do not distribute or upload anywhere. It's experimental only.

I wouldn't just experiment.

I may try the IOCTL work-arrounds you mentioned earlier,
or wait for an AMOUSE update ...

Regards, JvW 

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
10/25/2005 4:47:33 AM
On Tue, 25 Oct 2005 04:47:33 UTC, "Jan van Wijk" 
<jvw.no.spam@dfsee.com> wrote:

> On Mon, 24 Oct 2005 17:36:16 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
> Hello Lars,
> 
> > > Else you could send it to:
> > > 
> > >         jvw AT dfsee DOT com
> > > 
> > > TIA, Jan van Wijk 
> > > 
> > Find it here in the newsgroup, attached to my email from 23.10.2005.
> 
> I don't see any post from you on the 23rd, just 20, 21, 22 and 24 ...
> 
> Further I do not see any way to see/detach attachements 
> here in ProNews, allthough that may become clear as 
> soon as I see a message with an attachement :-)
> 
> The Help does not seem to function at all ...
> 
> > Please do not distribute or upload anywhere. It's experimental only.
> 
> I wouldn't just experiment.
> 
> I may try the IOCTL work-arrounds you mentioned earlier,
> or wait for an AMOUSE update ...
> 
> Regards, JvW 
> 

The attaachments are usually detached to the directory DECODED just 
below the Pronews root directory.

-- 
Lorne Sunley
0
Lorne
10/25/2005 5:10:42 AM
On Tue, 25 Oct 2005 04:47:33 UTC, "Jan van Wijk" 
<jvw.no.spam@dfsee.com> wrote:

> On Mon, 24 Oct 2005 17:36:16 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
> Hello Lars,
> 
> > > Else you could send it to:
> > > 
> > >         jvw AT dfsee DOT com
> > > 
> > > TIA, Jan van Wijk 
> > > 
> > Find it here in the newsgroup, attached to my email from 23.10.2005.
> 
> I don't see any post from you on the 23rd, just 20, 21, 22 and 24 ...
> 
> Further I do not see any way to see/detach attachements 
> here in ProNews, allthough that may become clear as 
> soon as I see a message with an attachement :-)
> 
> The Help does not seem to function at all ...
> 
> > Please do not distribute or upload anywhere. It's experimental only.
> 
> I wouldn't just experiment.
> 
> I may try the IOCTL work-arrounds you mentioned earlier,
> or wait for an AMOUSE update ...
> 
> Regards, JvW 
> 

There is a version 1.57 of Pronews/2 on http://hobbes.nmsu.edu the 
help works in that one (I just tried it)

-- 
Lorne Sunley
0
Lorne
10/25/2005 5:13:53 AM
Hi Lorne,

On Tue, 25 Oct 2005 05:10:42 UTC, "Lorne Sunley" <lsunley@mts.net> wrote:

> 
> The attaachments are usually detached to the directory DECODED just 
> below the Pronews root directory.
  
Thanks for the tip!

I did find several attachements there, but not one related
to this thread. I even refreshed by getting all headers again
and going through each message (some I had not seen).

Still nothing ...

Perhaps they are filtered somewhere on a server ?
I get these from the server at the university of berlin.

The ones I see attachements from are on the eCS server ...

Regards, JvW 

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
10/25/2005 10:40:23 AM
 > attaachments are usually detached to the directory DECODED just 
 > below the Pronews root directory.

The article with the attachment (spam-related?), and at least the 
attachment (binaries not desired here?), probably has been deleted
by several newsservers. Both of my newsservers missed the article
completely, which otherwise is very uncommon.



---
0
ML
10/25/2005 12:06:54 PM
I tried to send you the driver to the address listed on your website but 
I always get the message that it is invalid ...

Nospam05j@w-gregg.juneau.ak.us.invalid schrieb:
>   Re: Mouse cursor in OS2 full-screen sessions - new build of mouse.sys (Sat, 22 Oct 2005 16:58:29 +0200):
> 
> 
> As a non-programer, much of the discussion here is over my head, but
> if I understand correctly that there is an experimental mouse.sys with
> a possible fix in it, I'm sure willing to try it.  But there don't seem
> to be any pointers to the actual binary, at least, in the messages that
> have shown up here so far.
0
Lars
10/25/2005 9:02:56 PM
On 2. check,

your email system refuses attachments, no matter what file extension.

Lars

Nospam05j@w-gregg.juneau.ak.us.invalid schrieb:
> Quoting Lars Erdmann <lars.erdmann@arcor.de>,
>   Re: Mouse cursor in OS2 full-screen sessions - new build of mouse.sys (Sat, 22 Oct 2005 16:58:29 +0200):
> 
> 
> 
>>Ruediger Ihle schrieb:
>>
>>>On Fri, 21 Oct 2005 23:41:45 UTC, Lars Erdmann <lars.erdmann@arcor.de> 
>>>wrote:
>>>
>>>
>>>
>>>>I have now incorporated a tiny fix into mouse.sys and wonder if anyone 
>>>>is willing to test it on their system.
>>>
>>>
>>>Could you please contact Mr. Breining http://www.nbsoftware.de
>>>and discuss the problem with him ?
>>>
>>>
>>
>>I already did as I am keen of getting it into their amouse.sys as well
>>:-)
> 
> 
>>Lars
> 
> 
> As a non-programer, much of the discussion here is over my head, but
> if I understand correctly that there is an experimental mouse.sys with
> a possible fix in it, I'm sure willing to try it.  But there don't seem
> to be any pointers to the actual binary, at least, in the messages that
> have shown up here so far.
> 
> Regarding my earlier post about it being mandatory to use full screen to use
> the compressed modes, what I meant is that selecting mode co132 in a window
> doesn't actually change the font at all here. It just gives a horizontal scroll
> bar until I muck with the window fonts and size, which is a real pain.  While
> in fullscreen, mode co132 actually changes to a true 132 column font that
> fits on screen, no muss, no fuss, every time.  Which is why a scrolling mouse
> driver with an unreliable fullscreen pointer isn't usable, from my point of
> view.  The plain mouse driver pointer works fine for me in fullscreen.  (One
> exception I guess I better disclose is that when I tried my copy of Lynx with
> the mouse enabled, it often started with the pointer 'frozen' in the middle of
> the screen, and other times vanished after a few screens.  But I'm pretty
> sure that's in Lynx, nothing else behaves this way.  And lynx works just fine
> without a mouse.)
> 
> 
0
Lars
10/25/2005 9:19:06 PM
Quoting Lars Erdmann <lars.erdmann@arcor.de>,
  Re: Mouse cursor in OS2 full-screen sessions - new build of mouse.sys (Tue, 25 Oct 2005 23:02:56 +0200):


>I tried to send you the driver to the address listed on your website but 
>I always get the message that it is invalid ...

Ouch.  My website address used to work and didn't have any munging or email
filtering, but I must have messed up somewhere.  It also goes through GMail
now, maybe they are blocking it.  Thanks for letting me know, I'll check into
that.  Meantime, I'll send you a direct address by email.  I'd really like to
check out that driver.  Thanks,


-- 
Walt (To email, remove .invalid from address, or visit
personal home page http://www.w-gregg.juneau.ak.us.)

0
Nospam05j
10/26/2005 1:46:22 AM
In <435ee134$2$jnyg$mr2ice@news.gci.net>, on 10/25/2005
   at 04:46 PM, Nospam05j@w-gregg.juneau.ak.us.invalid said:

>email filtering, but I must have messed up somewhere.  It also goes
>through GMail now, maybe they are blocking it.

GMail automatically strips attachments.


Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
10/26/2005 2:07:05 AM
On Thu, 20 Oct 2005 22:07:02 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

<snip>
> P.P.S: And yet another undocumented one that could help:
> Category 07h,Function 5Eh "GRADD - to register/deregister the task time 
> only pointer draw" with the following parameter packet (no data packet):
>  
> typedef struct _TSKTIME
> {
>     ULONG fTaskPtr;
> } TSKTIME, *PTSKTIME;
>  
> Obviously, this is fTaskPtr = 1 for registering and fTaskPtr = 0 for 
> deregistering.
>  
> Looking at the pointer draw code in file "util1.asm","DrawPointer" 
> function, I would try and set fTaskPtr=0 once on program start as that 
> should force a call to the draw function of the POINTER$ device driver 
> (POINTDD.SYS, which does the actual mouse pointer drawing).
>  
> Maybe I should give it a try ...
  
Well after testing the MOUSE.SYS replacement that Lars made, 
that indeed solves the problem for me, I decided to test this 
work-arround as well.


I have added the following code to initialization in my TxWin library:

+++++++++++ TxWin init snippet for OS2

#define MOU_GRADD_REGISTER           0x005E     // undocumented, fixes
                                                // draw-bug in FS sessions
typedef struct _TSKTIME
{
    ULONG fTaskPtr;                             // 1 = register, 0=deregister
} TSKTIME, *PTSKTIME;


	// and the in the actual init function:

            if (DosOpen((PSZ) "MOUSE$",         // need RAW device, not MOU
                         &txw_hmou32, &act, 0,  FILE_NORMAL,        
                         OPEN_ACTION_OPEN_IF_EXISTS, // do not create
                         OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE,   
                         0) == NO_ERROR)                 
            {
               TSKTIME  tsktime  = {0};
               ULONG    ParamLen = sizeof(tsktime);

               DosDevIOCtl( txw_hmou32, 
                            IOCTL_POINTINGDEVICE, MOU_GRADD_REGISTER,
                            &tsktime, ParamLen, &ParamLen, NULL, 0, 0);
            }

+++++++++++

And this fixes the problem for TxWindows applications (like DFSee :-)
(without a mouse.sys fix in place of course)

Many thanks to Lars for investigating and solving this!

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
10/26/2005 11:27:03 AM
Steven Levine schrieb:
> In <435ee134$2$jnyg$mr2ice@news.gci.net>, on 10/25/2005
>    at 04:46 PM, Nospam05j@w-gregg.juneau.ak.us.invalid said:
> 
> 
>>email filtering, but I must have messed up somewhere.  It also goes
>>through GMail now, maybe they are blocking it.
> 
> 
> GMail automatically strips attachments.
> 
> 
> Steven
> 
Yes, in the return header it was stated that Gmail had deleted an 
invalid attachment (or so).

Lars
0
Lars
10/26/2005 4:35:15 PM
Great, then I can be sure (or have a good probability) that my fix to 
mouse.sys works.
Now I am awaiting the Amouse author's response as I have also proposed 
the fix to his amouse.sys which builds upon mouse.sys DDK sources.

Lars

Jan van Wijk schrieb:
> On Thu, 20 Oct 2005 22:07:02 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:
> 
> <snip>
> 
>>P.P.S: And yet another undocumented one that could help:
>>Category 07h,Function 5Eh "GRADD - to register/deregister the task time 
>>only pointer draw" with the following parameter packet (no data packet):
>> 
>>typedef struct _TSKTIME
>>{
>>    ULONG fTaskPtr;
>>} TSKTIME, *PTSKTIME;
>> 
>>Obviously, this is fTaskPtr = 1 for registering and fTaskPtr = 0 for 
>>deregistering.
>> 
>>Looking at the pointer draw code in file "util1.asm","DrawPointer" 
>>function, I would try and set fTaskPtr=0 once on program start as that 
>>should force a call to the draw function of the POINTER$ device driver 
>>(POINTDD.SYS, which does the actual mouse pointer drawing).
>> 
>>Maybe I should give it a try ...
> 
>   
> Well after testing the MOUSE.SYS replacement that Lars made, 
> that indeed solves the problem for me, I decided to test this 
> work-arround as well.
> 
> 
> I have added the following code to initialization in my TxWin library:
> 
> +++++++++++ TxWin init snippet for OS2
> 
> #define MOU_GRADD_REGISTER           0x005E     // undocumented, fixes
>                                                 // draw-bug in FS sessions
> typedef struct _TSKTIME
> {
>     ULONG fTaskPtr;                             // 1 = register, 0=deregister
> } TSKTIME, *PTSKTIME;
> 
> 
> 	// and the in the actual init function:
> 
>             if (DosOpen((PSZ) "MOUSE$",         // need RAW device, not MOU
>                          &txw_hmou32, &act, 0,  FILE_NORMAL,        
>                          OPEN_ACTION_OPEN_IF_EXISTS, // do not create
>                          OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE,   
>                          0) == NO_ERROR)                 
>             {
>                TSKTIME  tsktime  = {0};
>                ULONG    ParamLen = sizeof(tsktime);
> 
>                DosDevIOCtl( txw_hmou32, 
>                             IOCTL_POINTINGDEVICE, MOU_GRADD_REGISTER,
>                             &tsktime, ParamLen, &ParamLen, NULL, 0, 0);
>             }
> 
> +++++++++++
> 
> And this fixes the problem for TxWindows applications (like DFSee :-)
> (without a mouse.sys fix in place of course)
> 
> Many thanks to Lars for investigating and solving this!
> 
0
Lars
10/26/2005 4:38:43 PM
Quoting Lars Erdmann <lars.erdmann@arcor.de>,
  Re: Mouse cursor in OS2 full-screen sessions (Wed, 26 Oct 2005 18:38:43 +0200):


>Great, then I can be sure (or have a good probability) that my fix to 
>mouse.sys works.
>Now I am awaiting the Amouse author's response as I have also proposed 
>the fix to his amouse.sys which builds upon mouse.sys DDK sources.

Bravo on the new mouse.sys.  This scrolling mouse driver has a visible
pointer in full screen os/2 100% of the time now for me.  Works in the JED
editor, RAR compresser, and several branches of Links (links 0.99, elinks
0.4pre6, and [g]links 2.1pre14. The only thing that still seems erratic is
the Lynx 2.8.5 mouse pointer, but I think that's a bug in Lynx itself
(because sometimes it works for a while and then vanishes).  Everything else
seems perfect.  I've opened and closed dozens of full screen sessions, tried
rebooting, running with different programs open, etc, and the pointer in my
full screen os/2 session stays on the job no matter what. I do understand
the driver is still a draft and not to be redistributed at this point, but I
think you can indeed be sure your fix works!



-- 
Walt (To email, remove .invalid from address, or visit
personal home page http://www.w-gregg.juneau.ak.us.)

0
Nospam05j
10/26/2005 10:42:29 PM
Hallo Jan,

>   
> Well after testing the MOUSE.SYS replacement that Lars made, 
> that indeed solves the problem for me, I decided to test this 
> work-arround as well.
> 
> 
> I have added the following code to initialization in my TxWin library:
> 
> +++++++++++ TxWin init snippet for OS2
> 
> #define MOU_GRADD_REGISTER           0x005E     // undocumented, fixes
>                                                 // draw-bug in FS sessions
> typedef struct _TSKTIME
> {
>     ULONG fTaskPtr;                             // 1 = register, 0=deregister
> } TSKTIME, *PTSKTIME;
> 
> 
> 	// and the in the actual init function:
> 
>             if (DosOpen((PSZ) "MOUSE$",         // need RAW device, not MOU
>                          &txw_hmou32, &act, 0,  FILE_NORMAL,        
>                          OPEN_ACTION_OPEN_IF_EXISTS, // do not create
>                          OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE,   
>                          0) == NO_ERROR)                 
>             {
>                TSKTIME  tsktime  = {0};
>                ULONG    ParamLen = sizeof(tsktime);
> 
>                DosDevIOCtl( txw_hmou32, 
>                             IOCTL_POINTINGDEVICE, MOU_GRADD_REGISTER,
>                             &tsktime, ParamLen, &ParamLen, NULL, 0, 0);
>             }
> 
> +++++++++++
> 
> And this fixes the problem for TxWindows applications (like DFSee :-)
> (without a mouse.sys fix in place of course)

Thinking about it, that might be a not so good idea. I think the IOCTL 
is meant to be used from GRADD Display Drivers to suppress ("register") 
and to reenable ("deregister") the mouse cursor (maybe GRADD display 
drivers can elect to do the mouse pointer drawing themselves, I don't know).
So there is a chance that the "workaround" will negatively interact with 
a Display driver that elected to suppress Mouse Pointer drawing where 
you then reenable it without the display driver knowing. Fortunately the 
problem is then restricted to YOUR app and not to the whole system.
At least I would suggest that you allow to configure this "workaround" 
through enabling/disabling it through an ini file or alike.

1.) I will upload the fix to Hobbes in the next couple of days. So then 
everyone has a chance to fix his system.

2.) Scott Garfinkle has taken the fix to the people in charge. There is 
a slight chance that it will get incorporated in the official mouse.sys.


Lars
0
Lars
10/30/2005 9:56:56 AM
Hi Lars,

On Sun, 30 Oct 2005 09:56:56 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

> > And this fixes the problem for TxWindows applications (like DFSee :-)
> > (without a mouse.sys fix in place of course)
>  
> Thinking about it, that might be a not so good idea. I think the IOCTL 
> is meant to be used from GRADD Display Drivers to suppress ("register") 
> and to reenable ("deregister") the mouse cursor (maybe GRADD display 
> drivers can elect to do the mouse pointer drawing themselves, I don't know).

OK

> So there is a chance that the "workaround" will negatively interact with 
> a Display driver that elected to suppress Mouse Pointer drawing where 
> you then reenable it without the display driver knowing. Fortunately the 
> problem is then restricted to YOUR app and not to the whole system.
> At least I would suggest that you allow to configure this "workaround" 
> through enabling/disabling it through an ini file or alike.

Yes, that is a good idea, actually, I think I will simplay add
an explicit switch you have to use to ENABLE this workarround.

Something like:

	DFSOS2  -fsmouse

  
> 1.) I will upload the fix to Hobbes in the next couple of days. So then 
> everyone has a chance to fix his system.

OK, nice.
  
> 2.) Scott Garfinkle has taken the fix to the people in charge. There is 
> a slight chance that it will get incorporated in the official mouse.sys.
  
Yes, I saw the positing, would be great.

Regards, JvW 

-- 
Jan van Wijk; Author of DFSee: http://www.dfsee.com
0
Jan
10/30/2005 12:05:10 PM
Sir:

ML wrote:
>  > are you using SNAP ? I am asking as I have it installed and the exact 
>  > same problem than you while others do not seem to have the problem.
> 
> Same problem here, with eCS. 'Strange', it used to work with Warp 4
> just fine. I have to say it looks like the old MOUSE.SYS problem to
> me. The mouse cursor is there, but it isn't visible. If possible you
> could try the original MOUSE.SYS (backup the existing MOUSE.SYS first,
> obviously) of Warp 4, and see if that solves anything. Other than that,
> it could me SNAP too.
> 

In Xworkplace is an option to hid the mouse cursor.  It sound like that 
is enabled.  Look in the eworkplace tool properties.
-- 
Bill
Thanks a Million!
0
William
2/28/2014 1:01:01 AM
Reply:

Similar Artilces:

Full-screen session kills mouse pointer
OK, I've had this bug plaguing me for a long time, but it's finally getting to the point where it's beyond annoying. After I've opened and closed a few full-screen sessions (OS/2 Full Screen or Win-OS/2 Full Screen), the mouse pointer just stops working when I return to the WPS. CAD Handler in particular tends to trigger this after I've gone into it a few times. Nothing will bring the mouse back short of a reboot. How can I fix this? ISTR some other people mentioning it a couple of years back, but I haven't heard about it in a while, so I'm as...

OS2
hi, I look for CRACK SciTech SNAP 3.1.5 Graphics for OS/2? you can help me faiscaa@terra.es cidmail@terra.es wrote: > hi, I look for CRACK SciTech SNAP 3.1.5 Graphics for OS/2? > you can help me > faiscaa@terra.es > You can download a free "personal" version of SNAP from the Scitech website, limited to a single chipset. Otherwise, buy eComStation or buy SNAP from Mensys. Don't be cheap! Stuart On Thu, 6 Jul 2006 14:29:00 UTC, Srtgray <srtgrayNOT@clara.co.uk> wrote: you can say the route to me for download? > cidmail@terra.es...

OS2
I got a free copy of OS2 with books is it worth anything ? can i use it on a new computer or do i need an older model? In <%W6ec.1345$By1.904@news01.roc.ny>, on 04/11/2004 at 08:00 AM, "jaonajames" <jaonajames@nowhere.com> said: >I got a free copy of OS2 with books is it worth anything ? can i use it >on a new computer or do i need an older model? You have to tell us what version of OS2, and what the computer is -- before anyone can give you information. jaonajames <jaonajames@nowhere.com> wrote: > I got a free copy of OS2 with books is it wor...

Screen shots in OS2
How exactly can I capture a screenshot and save it as an image file on OS2? "=2E =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): " > How exactly can I capture a screenshot and save it as an image file on OS= 2? Download PMView -- http://pmview.com Install the application, File -> Capture -> .. .. wrote: > How exactly can I capture a screenshot and save it as an image file on OS2? The Embellish application does that. Download at: http://hobbes.nmsu.edu Search for the file embos2.zip, unzip, and install. Then select File ==> Image Acquire ==> Screen Capture PM Vie...

What do a OS2 do?
hmmmm? Why would I want to use and advocate for won? -- Grizzly H. mixed nuts <melopsitticus@undulatus.budgie> writes: 19> Newsgroups: alt.alien.vampire.flonk.flonk.flonk,comp.os.os2.advocacy 19> hmmmm? Why would I want to use and advocate for won? What do your questions have to do with OS/2, nuts? On 3 Sep., 21:58, "tho...@antispam.ham" <tho...@ifa.hawaii.edu> wrote: > mixed nuts <melopsitti...@undulatus.budgie> writes: > > 19> Newsgroups: > alt.alien.vampire.flonk.flonk.flonk,comp.os.os2.advocacy > > 19> hmm...

Track Mouse Movement when the cursor is off screen?
I have the opportunity to rescue a project that uses a mouse to sense the relative position of a machine. The hardware is built...just needs to be programmed. Stop snickering!!! I didn't do it...I just gotta fix it. I need to make some calculations on the measurements and VB6 is my language. Yes, the system mouse will corrupt the measurement, but it's an auditing function and that's acceptable. Everything I've tried so far requires resetting the mouse cursor to a known position on the screen at the start of the machine cycle. That sorta works, but makes it impossible for t...

Warp 4: when are the files OS2.INI and OS2SYS.INI created in the OS2 directory?
I just installed Warp 4. I can find the files OS2.INI and OS2SYS.INI in the OS2\INSTALL directory. What conditions trigger their creation in the OS2 directory? Thank you for your answer. -- Jean Castonguay �lectrocommande Pascal On Fri, 10 Dec 2004 05:11:53 UTC, "Jean Castonguay" <jcastong@riq.qc.ca> wrote: > I just installed Warp 4. > > I can find the files OS2.INI and OS2SYS.INI in the OS2\INSTALL > directory. > What conditions trigger their creation in the OS2 directory? > > Thank you for your answer. The ones in the \OS...

looking for painting software in full screen ??looking for painting full screen software ??
looking for painting software in full screen ??looking for painting full screen software ?? In news:Xns9439E85DC82C1arrrrghotmailcom@213.228.0.75, Arrrrg typed: > looking for painting software in full screen ??looking for painting > full screen software ?? No, I don't. -- www.zenobits.com ...

help with USB mouse on OS2 warp 4
HI, My PS2 port does not work and for a while I was using Serial to PS2 connector to hook my mouse up to the PC running OS2, now that stopped working all of a sudden. I tried plugging in a USB mouse hoping it will detect it, it still doesn't. I checked the settings and it is on autodetect on USB settings on BIOS. I do not know if I have USB drivers installed on the system. Any ideas how can I connect a USB mouse to this PC and if there are any drivers out there that I should install? IF I cannot use USB for this any idea why my both serial ports are not working for mouse ...

PDF full screen navigation using mouse
I currently use the latex package prosper to create PDFs for full screen presentations in acroread. Currently, to move back/forward a slide, I press left/right arrow keys. I'd like to use a remote control mouse, but my version of acroread (5.0) only allows mouse clicks to move forward to the next page. If I want to move backwards, it seems that I have to revert to the keyboard. Has anyone got any solutions to this? I think I need to stick with acroread rather than xpdf, since sometimes I show presentations under Windows rather than a linux machine. i.e. one thought I had was to have ...

VMware guest OS full-screen problem
VMWare (5.5.1 build-19175) on FC4. After installing VMware tools (on the doze XP guest) I can't run it full-screen anymore. The refresh rate probably is at fault. At 1280x1024 my TFT can't top 75Hz, and VMware sets it at 89. (screen does show, but slightly garbled.) For now I use the F11-semi-fullscreen mode. Have been looking for the right location to set/overrule this frequency, to no avail. Not in the guest, nor the host. VMWare forums did not offer a helpful clue. Anyone ? TIA Sh. On Sat, 01 Apr 2006 18:26:36 +0200, Schraalhans Keukenmeester <schraalhans.keukenmeester@ge...

WTB:Mouse or Trackball and OS2.05 Disks
Well I found my 4MB Retina Z2 card and will be using that for my RTG. In fact I am going to try and make it CyberGrapX Compatible by first switching it over to EGS Mode first, then loading the Cyber Driver for it. Hopefully it will detect the Graphics Mode instead of the card ID. Anyway, the Retina Z2 worked great for me just using the standard Retina Z2 Drivers in workbench, and since I pretty much only play games on disks anyway that's all I need for Graphics. However I can't do any of that without first getting a Mouse or Trackball, and Some OS2 Software. I'd pr...

installing USB mouse on OS2 warp 4
HI, My PS2 port does not work and for a while I was using Serial to PS2 connector to hook my mouse up to the PC running OS2, now that stopped working all of a sudden. I tried plugging in a USB mouse hoping it will detect it, it still doesn't. I checked the settings and it is on autodetect on USB settings on BIOS. I do not know if I have USB drivers installed on the system. Any ideas how can I connect a USB mouse to this PC and if there are any drivers out there that I should install? Thanks in advance for the help, On 12 Mar 2007 19:00:33 -0700, kamalsharma31@gmail.com...

Windows cursor on full-screen DOS-Prompt...
Is it possible to force the appearance of the mouse cursor on a full-screen DOS-prompt? CaptainBirdsEye wrote: > Is it possible to force the appearance of the mouse cursor on > a full-screen DOS-prompt? It's a completely different video mode - text vs graphics. The best you can do is get a "block". There should be special software for doing so, but I don't know of any standard solution. -- Martijn http://www.sereneconcepts.nl ...

Web resources about - Mouse cursor in OS2 full-screen sessions - comp.os.os2.programmer.misc

App Store - Atomic Web Browser - Full Screen Tabbed Browser w/ Download Manager & Dropbox
Read reviews, get customer ratings, see screenshots, and learn more about Atomic Web Browser - Full Screen Tabbed Browser w/ Download Manager ...

Custom Android Boot Animation - "Android Destroys Apple" (Full-screen) - YouTube
Android Custom Boot Animation - "Android Destroys Apple" (Full-screen) Here it is, the boot animation everybody has been requesting! New and ...

Google AdWords full-screen in-app ads get a little prettier with redesign
There might not be any topic more heated in today's digital space than advertising. In most cases, no ads is better than any ads at all. The ...

Gmail iOS app gets new icon, full-screen mode for large images & better integration w/ Google apps
... app includes an “enhanced attachment experience,” which really means that a larger image attached to an email will now open in a new full screen ...

Apple Bringing Full-Screen Video iAds to Mobile
... to an iPad near you: iAds that look a lot like TV ads. Apple will roll out new video iAds this year that will automatically play full-screen ...


Chrome for Android updated, brings full screen browsing
Full screen browsing and simpler searching highlight the changes in Chrome 27 for Android

Chrome Beta for Android found to be hiding a full-screen browsing mode
It seems Google may have hidden a full-screen browsing mode in the latest Chrome Beta release. Though, before anyone thinks of switching to the ...

Amazon Kindle Fire's Firmware Update (To 6.2.2) Breaks Root, Adds Full-Screen Browsing
In a familiar turn of events, Amazon has pushed out another root-breaking firmware update, bringing the Kindle Fire's firmware up to version ...

Report: Apple Will Introduce Full-Screen Video iAds To Apps In 2014
... get a lot bigger and more annoying. According to AdAge , Apple will roll out new ads in apps that automatically play on the full screen of an ...

Resources last updated: 1/31/2016 6:34:24 AM