How can I say "You pressed Down Arrow Key" ?

[dedndave]

ok - the issue is this
in the user32.inc file (and DLL), the name ShowCursor is already PROTO'd with a DWORD parm   :bg
just modify the name a little
ShwCursor

[frktons]

Thanks Dave, I found this one and some syntax errors like dispaly instead of display.
By the way, I got rid of the PROTO, corrected the syntax error and used ShowTheCursor
instead of ShowCursor.
Now it compiles, but if freezes when it has to dispaly the screen.
I think it depends on:

Code Select Expand


GetConsole PROC

    mov hFile, fopen(DWORD PTR FmtName)

    mov ebx, fread(hFile, offset menusys, BufLen)
   
    fclose hFile

    ret
   
GetConsole ENDP


I should pass the string name to fopen() macro, but I passed a DWORD PTR to it.
Maybe this is another error....  ::)

[dedndave]

pass the address (pointer) to the string name
then, you will want to use INVOKE and PROTO for that function (don't have to do it that way if you don't want)

[frktons]

Well I tryed with

Code Select Expand


BufLen  EQU BufRows*BufCols*4  ;string length (tchars)


I didn't multiply by four  :red

and I used the string name instead of the DWORD PTR to it,
maybe the MACRO doesn't like anything different than a string literal.

Now it works.  :U

What do you suggest? Instead of using the MACRO fopen() I could
use something similar but not the MACRO? a function?

[dedndave]

no - what i meant was - you may want to use that function to open and read different screen data files
so, pass a parameter to that PROC that is a pointer to the filename string
that way, you can...

Code Select Expand

INVOKE GetConsole,offset Filename1
.
.
INVOKE GetConsole,offset Filename2
.
.
INVOKE GetConsole,offset Filename3

[frktons]

no - what i meant was - you may want to use that function to open and read different screen data files
so, pass a parameter to that PROC that is a pointer to the filename string
that way, you can...

Code Select Expand

INVOKE GetConsole,offset Filename1
.
.
INVOKE GetConsole,offset Filename2
.
.
INVOKE GetConsole,offset Filename3

Well, this was my original intent, but apparentely it doesn't work.
Let me try again...

[dedndave]

Code Select Expand

GetConsole PROTO :DWORD



GetConsole PROC szFileName:DWORD

   mov hFile, fopen(szFileName)

   mov ebx, fread(hFile, offset menusys, BufLen)
 
   fclose hFile

   ret
 
GetConsole ENDP

not sure about fopen - i usually write my own function for that
you may have to get the pointer into a register, first

Code Select Expand

GetConsole PROC szFileName:DWORD

   mov eax,szFileName
   mov hFile, fopen(eax)

[frktons]

Code Select Expand

GetConsole PROTO :DWORD



GetConsole PROC szFileName:DWORD

   mov hFile, fopen(szFileName)

   mov ebx, fread(hFile, offset menusys, BufLen)
 
   fclose hFile

   ret
 
GetConsole ENDP

not sure about fopen - i usually write my own function for that
you may have to get the pointer into a register, first

Code Select Expand

GetConsole PROC szFileName:DWORD

   mov eax,szFileName
   mov hFile, fopen(eax)

Well, it works both ways, with and without eax.  :U

OK! the original intent is now fulfilled. Thanks Master once again  :P

A last thing: what do you think of the overall prog organization?
I've tryed to write it in a modular way in order to use it as a base
for the complete program. Any comment/suggestion?

Something I had to generalize was the DisplayFmt PROC
so I rewrote it this way:

Code Select Expand


; -------------------------------------------------------------------------

DisplayFmt PROC szFmtName:DWORD

    INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
           DWORD PTR startPoint, offset windowSize

    ret

DisplayFmt ENDP


Now I can use DisplayFmt to display any screen passing its offset.  :U

[dedndave]

well - as far as the way things are split up, it is ok
you can look at mine for a little guiidance, although mine was just something to get it working
thing is - you will have a better feel for how it can be modularized as you get closer to finishing it
pieces of code that you use again and again can made into be PROC's
in some cases, taking some code out of a PROC makes it usable for more things
you may not have a feel for this until you get some code going - lol
this is especially true for beginners

[frktons]

The actual version attached with the appropriate screen to display.
If you want to have a look  :wink

[dedndave]

well - one thing i would probably change...

Code Select Expand

DisplayFmt PROC szFmtName:DWORD

    INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
           DWORD PTR startPoint, offset windowSize

    ret

DisplayFmt ENDP

i wouldn't make that a PROC at all
just INVOKE the function inline

Code Select Expand

Main PROC

    CALL   InitProc

    CALL   ConsoleSize

    INVOKE GetConsole, offset FmtName

    INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
           DWORD PTR startPoint, offset windowSize
       
    CALL   AnyKey

    CALL   ShowTheCursor

finish: INVOKE ExitProcess,0

        ret

Main ENDP

[frktons]

well - one thing i would probably change...

Code Select Expand

DisplayFmt PROC szFmtName:DWORD

    INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
           DWORD PTR startPoint, offset windowSize

    ret

DisplayFmt ENDP

i wouldn't make that a PROC at all
just INVOKE the function inline

Code Select Expand

Main PROC

    CALL   InitProc

    CALL   ConsoleSize

    INVOKE GetConsole, offset FmtName

    INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
           DWORD PTR startPoint, offset windowSize
       
    CALL   AnyKey

    CALL   ShowTheCursor

finish: INVOKE ExitProcess,0

        ret

Main ENDP

Sorry Master, but I think this time I have to disagree, maybe.
Let me explain. I'll use DisplayFmt PROC in many places in the
program to display various screen.
If I don't make it a PROC I'll have to rewrite the:

Code Select Expand


    INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
           DWORD PTR startPoint, offset windowSize

many times, and repeat the same code dozens of times.
If I got what you mean, of course. Maybe I didn't understand.
Can you please explain why do you suggest this change?

[dedndave]

well - by making it a PROC, you add the overhead of a CALL and a RET, as well as the PUSH for the parm
if you want to save typing, make a macro out of it   :U
or do like me and use copy/paste - lol

[frktons]

well - by making it a PROC, you add the overhead of a CALL and a RET, as well as the PUSH for the parm
if you want to save typing, make a macro out of it   :U

In order to spare some cycle you suggest to inflate the size of the program?
Well. For the time being I think the PROC is the clean solution I need.
The MACRO could be a good compromise, but I'm actually not able to write it,
even if I suppose it is not that difficult  :P

Anyway I'll think about it.  :wink
And I'll study the MACRO as well, but after my holydays, maybe from the end
of september  :bg

[dedndave]

well - you're right about the clock cycles - that isn't going to make any difference
i hadn't thought about the byte-count for pushing all the parms
i suppose it depends on how many times you are going to use it