mouseptr question again...

[Scott Wolfington]

The thread on my last post got off on a tangent so I'm
going to post again. Thanks!

I'm experiencing some strange things with the mouseptr
function (it's probably only strange to me because I
probably don't know how it really works). At the
beginning of this function I set the mouse pointer
to 11 (busy) and at the end I set it back to 0
(default). What's weird is that it goes back to 0
(default) before the loop is done. Any ideas?
This function get's called from the CALLBACK function
of a DDT button. Thanks again for all your help!

Regards,
Scott
ps. I XXX'd out all the SQLTools commands since I'm not
sure if I'm allowed to post them.

FUNCTION MainAction(BYREF pUserChoices AS UserChoices) AS LONG


    LOCAL sSql         AS STRING
    LOCAL x            AS LONG
    LOCAL lStmtNumber  AS LONG
    LOCAL sResult      AS STRING
 
 
    MOUSEPTR 11
 
 
    'Let's create our SQL strings.
    sSql$ = BuildSqlStatement(pUserChoices)
 
 
    '#############################################################
    '#  Let's open the table and start looping through.          #
    '#############################################################
    lStmtNumber& = SQL_XXXXXXX(1)
 
    'Let's open our resultset.
    SQL_XXXXXXXX 1, lStmtNumber&, %IMMEDIATE, sSql$
 
    'Now let's loop through the resultset.
    DO
        SQL_XXXXXXXX 1, lStmtNumber&, %XXXX_ROW
        IF SQL_XXXXXXX(1, lStmtNumber&) THEN EXIT LOOP
 	
        'Do some stuff right here...
 
        x=x+1
 
        'Let's display some output.
        IF x MOD 100 = 0 THEN
            CONTROL SET TEXT hPage5Dlg&, %frmMain_lblRecordCount, STR$(x)
            DIALOG DOEVENTS
        END IF
 
        SLEEP(0)
 
    LOOP
 
    CONTROL SET TEXT hPage5Dlg&, %frmMain_lblRecordCount, STR$(x)
 
    MOUSEPTR 0
 
    'Close the SQL Resultset.
    SQL_XXXXXXXX 1, lStmtNumber&
 
    MainAction = 0
 
 
END FUNCTION

[Edwin Knoppert]

Sure.

Allmost ANY window class registers a mouse.
When you create SDk style windows, you may set a cursor, or not.

Because of your use of dialog doevents, windows notices the mousemovements you make and sends a WM_SETCURSOR to the window beneat.
Because of the class using the original mouse handle, this will restore the mouse.

I don't use doevents unless there's is a VERY special reason.

Setting the mouse to 11 is ideal, no events, the mouse will be restored by underlaying window autom.

If you want to keep the mouse:

Case %WM_SETCURSOR

SetCursor handle (11)
FUNCTION = 1 (< not sure)



------------------
[email protected]