No announcement yet.

Function from string, or something else?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Function from string, or something else?

    This may not be possible (but maybe it is)
    What I would like to do is write a function that would be a wrapper to another function. IE: if I were calling "SetWindowLong(hWnd, nIndex, dwNewLong)" that instead I would write it as "LogFunctionSub(SetWindowLong(hWnd, nIndex, dwNewLong))" which LogFunctionSub would write to a log file the function and parameters passed, and then call the original function I meant to call.

    Sort of like logging with CallStk$ except that logs my functions, not functions or API that I call within my function.

    Not knowing that I am really calling "SetWindowLong" I was trying to figure out how to know that is what I am calling. I thought about CodePtr(CVQ(SetWindowLong)) but CVQ is limited to 8 bytes, so I wonder is there a way to determine the function I want to call and log it???

    CodePtr wants label | functionname | subname
    but what are the label | functionname | subname really under the hood?
    (This may be my solution if there is one)?????
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    >but what are the label | functionname | subname really under the hood?

    The are compile-time-only entities provided for the convenience of the programmer... just like variable names, UDT structures, etc.

    When a procedure is exported, only the name and a 'code pointer' ( offset) are stored in the PE header.

    If you want to keep track of "what procedure I am calling" you will have to make a table of some sort to relate a "procedure ID" to the "procedure name as used at compile time." .. or use the provided debugging functions eg TRACE, CALLSTK.

    (If you ever wondered why running with #TOOLS ON is a tad sluggish, that's why: because the program is looking up the "user name" of procedures, labels, etc).
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]