Can any WinNT/XP expert please advise why this code works fine w/ Win9x/ME, yet the digits do not display correctly w/ WinXP.

.data
TabCapCount DB 12 DUP ("0")
PkgCount DB 12 DUP ("0")

.code
.IF al == 1Dh ;a tab/cap count has occurred
push edi
lea edi, TabCapCount + 2
call SetTextColor, hDC,
call TextOut, hDC, X, Y, edi, 1
call SetTextColor, hDC, 0
mov al,
inc al
.IF al == 3Ah
; code here if 1's digit was 9 and 10's digit field needs to be incremented and 1's digit set back to 0
.ENDIF
mov , al
call TextOut, hDC, X, Y, edi, 1

I downloaded 'Portmon.exe' from Sysinternals.com and the 1Dh signals are coming in from a PIC microcontroller, yet this code is
not displaying them on the computer screen. Is it possible this is
a NULL termination problem? Once the desired qty has been
counted, the code above drops out of a loop, the digits are reset
to 0 and the PkgCount 3-digit counter is incremented. The coding
for this is the same as above and works fine w/ WinXP.

Any advice is most appreciated.
Posted on 2002-04-06 10:43:12 by DaveTX47
There are separate versions of PortMon for Win98 and XP/NT, are you using the correct one? Win98 version is likely to not work on XP or NT.
Posted on 2002-04-06 11:31:27 by Qweerdy
Yes, I checked that at the sysinternals.com site. Portmon shows the 1Dh signals are being read (ReadFile). For some reason, the problem is in the snippet of code I have written. The code works fine w/ the older versions of Win, but not w/ WinXP w/ its NT kernel.
Posted on 2002-04-06 15:35:59 by DaveTX47
Dave,

I think I see a problem with register preservation in the following piece of code,


; ===========================================

lea edi, TabCapCount + 2
call SetTextColor, hDC, [ColorSelect]
call TextOut, hDC, X, Y, edi, 1
call SetTextColor, hDC, 0

; ===========================================

You call SetTextColor before you use EDI in the folowing call to TextOut and this may change the value in EDI.

I have no way of testing it as I do not run XP but just to see if it is the problem, I would make a local variable and put EDI into it and use the local variable in TextOut instead.

Regards,

hutch@movsd.com
Posted on 2002-04-06 15:47:17 by hutch--
Hutch,

I've tried using the EBX, ESI, and as you see, the EDI w/ the same results. If you think about it, for each machine there are 6 digits - 3 for the Tab/Cap counter and 3 for the # Pkgs counter. The only difference is the X value and possibly the Y value, depending on how many machines you're using.

The code for # Pkgs is exactly the same as the code for # Tab/Caps w/ the exception of using: lea edi, PkgCount + 2 (for Machine #1). This counter works fine even w/ WinXP. That's what is so puzzling to me.

As far as setting up LOCAL variables, I don't think TASM recognizes local variables unless you are in MASM mode and I'm coding in IDEAL mode. I did, however, try commenting out TabCapCount and use TabCapCount1 DB "0",0 just to test the 1's digit. That didn't help.
Posted on 2002-04-07 11:02:23 by DaveTX47
Hmm... try this:



; ===========================================

lea edi, TabCapCount + 2
push edi
call SetTextColor, hDC, [ColorSelect]
pop edi
call TextOut, hDC, X, Y, edi, 1
call SetTextColor, hDC, 0

; ===========================================


That's what hutch advises, but just with pushing/poping the register wich get's surely modified by SetTextColor.
Posted on 2002-04-07 11:14:49 by bazik
I tried that also w/ the same results. If, for ex., you're counting 20 tabs/caps per vial, you see consistently the following:

0 0 0 ;at start
0 0 ;after some have counted 1's digit clears
0 1 4 ;after more tabs have counted you get this
0 0 0 ;pgm counter down to zero and resets

# Pkgs counter then increments from 000 to 001 to 002, etc. It works fine and as I said above the coding is exactly the same.

I guess I should just change my name to PUZZLED!:confused:
Posted on 2002-04-08 08:14:38 by DaveTX47
Dave,

What I would be inclined to do is write another proc in the app that allows you to isolate what is happening and test the output to get the results.

It is likely to be something really obscure and probably the best way to do it is to leave the existing code there but write another proc which you approach in a different manner just to test what is happening.

I think we have all found these bottlenecks from time to time and taking a fresh approach is usually the best way to deal with it.

Regards,

hutch@movsd.com
Posted on 2002-04-08 19:07:28 by hutch--