Announcement

Collapse
No announcement yet.

Is it a "Hack" or is it Memorex?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is it a "Hack" or is it Memorex?

    While working on some long-lost ideas of the past (Stuff I either could not grasp fully, or something more important came up, or just gave up) I started looking at different "Programming 101" things that keep creeping up from time to time (and never knew why it was so hard to solve?)

    So I started looking at the basics, and what I could do to alleviate the problems creeping up again in the future. (Stuff like ErrorHandling for things I did not grasp, or did not see, and later come back to bite me)

    Each step I find why others may have given up before me (or succeeded, and did not care to share, or meant to share and forgot to???)

    Anyways here is my latest idea, but not sure yet if it is "Just a work of Magic?" that I may be leading myself down the wrong road? or a heck of a job figuring out how log more closely the last known line of code that succeeded before a GPF???

    Code:
    #COMPILE EXE
    #DIM ALL
    #INCLUDE "Win32Api.inc"
    MACRO FUNCTION CallFunc(FunctionToCall) = FunctionToCall                                  'Call Replacement Function and Gather Info, then Call the Real Function
    MACRO CallSub(FunctionToCall) = FunctionToCall                                            'Call Replacement Subroutine and Gather Info, then Call the Real Subroutine
    
    FUNCTION PBMAIN () AS LONG
    '*** Demo Macro Replacement for Function (with no parameters)
         MSGBOX "GetLastError = " + STR$(CallFunc(GetLastError))
    '*** Demo Macro Replacement for Function (with parameters_
         LOCAL hDlg AS LONG
         DIALOG NEW %HWND_DESKTOP, "TestWindow", 0, 0, 100, 100 TO hDlg
         ShowWindow hDlg, %SW_SHOWNORMAL
         MSGBOX "GetWindow = " + STR$(CallFunc(GetWindow(hDlg, %GW_HWNDFIRST)))
    '*** Demo Macro Replacement for Function that I have not written a replacement for yet
         MSGBOX "GetActiveWindow = " + STR$(CallFunc(GetActiveWindow))
    '*** Demo Macro Replacement for a Subroutine (with parameters)
         CallSub(DragAcceptFiles(hDlg, %TRUE))
         MSGBOX "DragAcceptFiles is a subroutine (no return value)"
    END FUNCTION
    
    FUNCTION GetLastError ALIAS "GetLastError"() AS LONG
         LOCAL RealFunction AS DWORD
         LOCAL RealFunctionReply AS LONG
         RealFunction = GetProcAddress(GetModuleHandle("KERNEL32.DLL") , FUNCNAME$)           'Get Function (if exists)
         SELECT CASE RealFunction                                                             'Check if Function is loaded
              CASE 0                                                                          'Not Loaded
                   LoadLibrary "KERNEL32.DLL"                                                 'Load necessary dll
                   RealFunction = GetProcAddress(GetModuleHandle("KERNEL32.DLL") , FUNCNAME$) 'Get Function (if exists)
              CASE ELSE                                                                       'Loaded
         END SELECT
         IF RealFunction = 0 THEN EXIT FUNCTION                                               'If still not loaded then exit
    SetLastError 7      'Demo how return works (but must be here so other functions do not reset the value
         CALL DWORD RealFunction USING GetLastError() TO RealFunctionReply
         FUNCTION = RealFunctionReply                                                         'Return Reply
    END FUNCTION
    
    FUNCTION GetWindow(BYVAL hWnd AS DWORD, BYVAL wCmd AS DWORD) AS LONG
         LOCAL RealFunction AS DWORD
         LOCAL RealFunctionReply AS LONG
         RealFunction = GetProcAddress(GetModuleHandle("USER32.DLL") , FUNCNAME$)             'Get Function (if exists)
         SELECT CASE RealFunction                                                             'Check if Function is loaded
              CASE 0                                                                          'Not Loaded
                   LoadLibrary "USER32.DLL"                                                   'Load necessary dll
                   RealFunction = GetProcAddress(GetModuleHandle("USER32.DLL") , FUNCNAME$)   'Get Function (if exists)
              CASE ELSE                                                                       'Loaded
         END SELECT
         IF RealFunction = 0 THEN EXIT FUNCTION                                               'If still not loaded then exit
         CALL DWORD RealFunction USING GetWindow(hWnd, wCmd) TO RealFunctionReply             'Call Function
         FUNCTION = RealFunctionReply                                                         'Return Reply
    END FUNCTION
    
    SUB DragAcceptFiles(BYVAL hwnd AS DWORD, BYVAL fAccept AS LONG)
         LOCAL RealSub AS DWORD
         RealSub = GetProcAddress(GetModuleHandle("SHELL32.DLL") , FUNCNAME$)                 'Get Subroutine (if exists)
         SELECT CASE RealSub                                                                  'Check if Subroutine is loaded
              CASE 0                                                                          'Not Loaded
                   LoadLibrary "SHELL32.DLL"                                                  'Load necessary dll
                   RealSub = GetProcAddress(GetModuleHandle("SHELL32.DLL") , FUNCNAME$)       'Get Subroutine (if exists)
              CASE ELSE                                                                       'Loaded
         END SELECT
         IF RealSub = 0 THEN EXIT SUB                                                         'If still not loaded then exit
         CALL DWORD RealSub USING DragAcceptFiles(hWnd, fAccept)                              'Call Subroutine
    END SUB
    Am I headed down the wrong path? or have I found a path that may not have been seen before, but can greatly reduce my development and troubleshooting time?
    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
    I don't know how you got "GetLastError" in there as a user symbol (procedure name), when the same function is DECLAREd as an external in WIN32API.INC.

    I wonder what's getting called when you use "GetLastError"

    >.... the last known line of code that succeeded before a GPF???

    No, it's not the last line which SUCCEEDED, it's the last line which was ATTEMPTED.

    The simple answer to your problem is... Check your return codes after every WinAPI function call, and your ERR after every PB instrinsic, and STOP!! if you don't get "success."
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      I don't know how you got "GetLastError" in there as a user symbol (procedure name), when the same function is DECLAREd as an external in WIN32API.INC.
      Neither do I

      I just used that particular function as an example of what I tripped upon. and I only THINK (mind you THINK) is that at compile-time, my code takes precedence and if my declares are the same as what is in the "Win32API.inc" then no problem.
      (hence my wondering if a magical "Hey look over here, while I do this here")
      >.... the last known line of code that succeeded before a GPF???

      No, it's not the last line which SUCCEEDED, it's the last line which was ATTEMPTED.
      True.....who is to say I stepped EXACTLY in the same place twice on thin ice?? (I could think I did, and really be 1mm left or right, or not the same pressure, or a million things...and wind up cracking the ice and fall through)

      again hence (not sure if I am treading on uneasy ground or blindly falling to my freezing death )
      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? "

      Comment


      • #4
        The EXTERNAL function is called (WinAPI), and the compiler wont complain as long as your internal function uses the same parameters and return types.
        Scott Slater
        Summit Computer Networks, Inc.
        www.summitcn.com

        Comment


        • #5
          The EXTERNAL function is called (WinAPI), and the compiler wont complain as long as your internal function uses the same parameters and return types.
          It should complain.

          If you have
          Code:
           DECLARE FUNCTION FOO LIB "THEDLL.DLL"  (X AS LONG)  AS LONG
          AND
          Code:
          FUNCTION FOO (X AS LONG) AS LONG 
          
          ...
          END FUNCTION
          .. in your source code, how does the compiler know which version of FOO is to be called when it encounters the line ...
          Code:
            Z =   FOO(W)
          ???

          Answer, it can't. This should be spit back at compile time with a "Duplicate Procedure Name" error.

          MCM
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            Answer, it can't. This should be spit back at compile time with a "Duplicate Procedure Name" error.
            I agree it should. I tested this and it doesn't complain, and it does call the external function regardless of what order the DECLARE for the EXTERNAL and the actual INTERNAL function are in. So the internal function in such as case is just dead weight. The compiler should stop however if such a thing were ever encountered. Could cause a major debugging headache for the programmer.
            Scott Slater
            Summit Computer Networks, Inc.
            www.summitcn.com

            Comment


            • #7
              > Could cause a major debugging headache for the programmer

              Oh, pray, Tell me about it!!

              FWIW, maybe "bug reports" are handled the same as "new feature suggestions" and the more people who report one the faster it gets fixed?

              So send your code in as a bug report. You can tell them to file yours along with my report and sample code from about two months ago.
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Actually I believe it should not as I found this in the docs.
                Restrictions
                A Sub/Function may be imported and exported within the same module. That is, a function in the module may be stated as EXPORT, while a DECLARE in the same module specifies it as an imported function by the option LIB "filename.dll", as long as FILENAME.DLL is the name of the module. This may be particularly valuable when you wish to build an #INCLUDE file with all of the DECLARE statements for a project.
                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? "

                Comment


                • #9
                  That's not the same situation, Cliff. That refers to using an EXPORTed function in the same module

                  That's the way I read it, anyway.

                  Doesn't really make any difference, does it? When the compiler CANNOT KNOW which function you are calling, it simply MUST be a programmer error and the compiler should abort the compilation and report same.

                  MCM
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Submitted to PB to see what their take on things may be.???
                    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? "

                    Comment


                    • #11
                      This is not a bug. This feature is actually used by many customers and third party vendors.

                      Sincerely,
                      Jeff Daniels
                      PowerBASIC Staff
                      Good enough for me
                      And it solve a problem I have been struggling to solve. So I will run with it.
                      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? "

                      Comment


                      • #12
                        This is not a bug. This feature is actually used by many customers and third party vendors.
                        Feature? Oh, come on.

                        It is totally, absolutely, one hundred percent silly to allow an ambiguous definition of a user procedure It's even sillier to call it "feature."

                        Mr. Zale has shown remarkable spin-doctoring skills when explaining certain other, um, "unusual" behavior in the compiler. But this excuse - excuse me, make that "explanation" - lacks any sign of those skills, and is quite frankly (with apologies to disabled persons) "lame."

                        Mr. Daniels does, however, get twelve chutzpah points for his reply effort.

                        Which is twelve more points of any kind going to any PB customer or third-party vendor who, um, "utilizes" this so-called "feature."

                        MCM
                        PS: Why was I not graced with a reply when I reported this bug?
                        Michael Mattias
                        Tal Systems Inc. (retired)
                        Racine WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          Feature? Oh, come on.

                          It is totally, absolutely, one hundred percent silly to allow an ambiguous definition of a user procedure It's even sillier to call it "feature."
                          ambiguous? What is so ambiguous about it? (unless I TOTALLY misunderstand the keyword "MODULE" which to me means "each DLL, or EXE" even if a part of a "Parent" Exe or DLL would be considered a "MODULE")

                          Now in that frame of thinking my "Magical" code does make sense (sort of) as I did declare my functions exactly the same as what was declared for a different "Module" (aka: the same function in a different DLL such as "USER32" or "KERNEL32" which they would be different "MODULE's")

                          Now following that and what you yourself pointed out in many many MANY "Debates" from my attempting to understand the "ins-and-outs" of how a DLL works then
                          At the point where a DLL is loaded into memory during process startup, Windows only guarantees that the KERNEL32.DLL system library will be loaded in memory. On this basis, API calls made from within LIBMAIN must be restricted to the range of API functions present in KERNEL32.DLL, with the exception of the LoadLibrary, LoadLibraryEx, and FreeLibrary API functions.
                          In addition, code within LIBMAIN must not call API functions in any other DLL (for example, USER32.DLL, SHELL32.DLL, ADVAPU32.DLL, GDI32.DLL, etc), because some API functions in those DLLs may attempt to load other libraries via LoadLibrary, etc. For example, never call the MessageBox API function from within LIBMAIN, nor use the related MSGBOX function or MSGBOX statement.
                          Failure to observe these restrictions will result in Access Violation or General Protection Faults (GPFs), typically caused by the execution of code in DLLs that has yet to be initialized.
                          which to me means that the "Win32API.INC" in its own obscure way would violate that and create a GPF if a function did not exist or the DLL did not exist (But how likely is that?) '<---- and YES that was a point, it could happen but how often does it happen???

                          Anyways on a more simple point...how many *.inc files have you seen in your lifetime that declared the same function nearly the same way as another *.inc did? (This part I can see your point if I declared a LONG and you declared a DWORD) but anyways....

                          The short of it...My example calls my function, my function in turn gets a pointer to a function that just happens to have the same name (but in ANOTHER module (or to my frame of thinking) so I am not calling my own function in a loop) and then uses it and passes back the response to whatever called my function.

                          Sure I thought it maybe "Magic" or I may had found what might have been a "bug" not caught before, but after posting to see if I was thinking right, or completely :doh: or asking for a "Cleanup Isle 14" (Chuckle at a Gosta Post) I took it to the horses mouth to ask and see if I was onto something??? or WAYYYYYY off base???

                          It would appear I am on base and on the right track (till told otherwise)

                          Mr. Zale has shown remarkable spin-doctoring skills when explaining certain other, um, "unusual" behavior in the compiler. But this excuse - excuse me, make that "explanation" - lacks any sign of those skills, and is quite frankly (with apologies to disabled persons) "lame."
                          Where did Mr. Zale come in???? I did NOT get my information from him directly, nor has he chimed in a word of warning and I think should not be involved as being a "Spin Doctor" until he has done so to be here to defend himself ("Its always sooooo easy to attack those not there to defend themselves")
                          Mr. Daniels does, however, get twelve chutzpah points for his reply effort.

                          Which is twelve more points of any kind going to any PB customer or third-party vendor who, um, "utilizes" this so-called "feature."
                          Yes he does (as do all the guys at PB for not only replying in a timely manner but in a MUCH-ABOVE timely manner (compared to companies I have dealt with)
                          MCM
                          PS: Why was I not graced with a reply when I reported this bug?
                          Ummmm...to be gentle...."Do you bit the hand that feeds you" when you submit a NFS or a bug report?
                          That can get you absolutely nowhere when you do not know all the details about something and WILL put off those that would help if they did not feel like they were being accused of something.


                          PS... Every time I have submitted (even in the beginning) and expected it may take days to respond, I had some sort of response in under hours (actually wayyyyy less than that but would not want to impose that on anyone) so I never have seen your response of "No Reply" :shhh:
                          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? "

                          Comment


                          • #14
                            >ambiguous? What is so ambiguous about it? ..unless I TOTALLY misunderstand ...

                            You must totally misunderstand.

                            See example in post #5 this thread. The call to FOO() is ambiguous.
                            Michael Mattias
                            Tal Systems Inc. (retired)
                            Racine WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              I must admit that I'm confused. Perhaps I'm not understanding the semantics of the word "module". If I declare a function in a DLL in my code, I am importing that function into my current process space. I'm not sure what the difference between module and process is apparently.

                              I agree with Michael, though, that this situation could be a debugging headache. If I do this:

                              Code:
                              DECLARE FUNCTION Test LIB "zdll.dll" ALIAS "Test" () AS LONG
                              
                              FUNCTION Test() AS LONG
                              
                                  FUNCTION = 42
                              
                              END FUNCTION
                              
                              FUNCTION PBMAIN () AS LONG
                              
                                  MSGBOX FORMAT$(Test)
                              
                              END FUNCTION
                              I get no error, the code compiles and runs but I do not get 42 displayed in the message box like I could reasonably expect. If the declare statement were buried in a large include file or included by an included file, trying to figure out why I wasn't getting the right value back could be difficult.

                              If I change my function line to:

                              Code:
                              FUNCTION Test(param AS LONG) AS LONG
                              I get a mismatch with prior definition error which tells me that I've got two functions with the same name.

                              If I do this:

                              Code:
                              DECLARE FUNCTION Test LIB "zdll.dll" ALIAS "Test" () AS LONG
                              
                              GLOBAL Test AS LONG
                              
                              FUNCTION PBMAIN () AS LONG
                              
                                  MSGBOX FORMAT$(Test)
                              
                              END FUNCTION
                              The compiler gives me a duplicate name definintion error on the GLOBAL line.

                              If I do this:

                              Code:
                              FUNCTION Test() AS LONG
                              
                                  FUNCTION = 24
                              
                              END FUNCTION
                              
                              FUNCTION Test() AS LONG
                              
                                  FUNCTION = 42
                              
                              END FUNCTION
                              
                              FUNCTION PBMAIN () AS LONG
                              
                                  MSGBOX FORMAT$(Test())
                              
                              END FUNCTION
                              I get a duplicate name definition on the second function named "Test".

                              If I write two DLLs with a "Test" function and one returns 24 and the other 42 and use this code:

                              Code:
                              DECLARE FUNCTION Test LIB "zdll24.dll" ALIAS "Test" () AS LONG
                              DECLARE FUNCTION Test LIB "zdll42.dll" ALIAS "Test" () AS LONG
                              
                              FUNCTION PBMAIN () AS LONG
                              
                                  MSGBOX FORMAT$(Test())
                              
                              END FUNCTION
                              I don't get any errors but only the most recently declared "Test" function gets called. In this case I got 42 but if I put the zdll42.dll declare first, I get 24. If I then change the second DLL to have a parameter passed in, I get a ")" expected error on that second declare.

                              So the only time you don't get errors is when the names, parameters and return type are the same and you are either overriding a local procedure of that name or you are overriding an earlier declare of that same name.

                              I can see no benefit but can see a downside. I would much prefer the compiler to at least warn me that there is a potential problem.
                              Jeff Blakeney

                              Comment


                              • #16
                                You can call both functions this way...

                                Code:
                                #Compile Exe
                                #Dim All
                                 
                                Declare Function test Lib "TestDll.dll" Alias "test" As Dword
                                 
                                Function test As Dword
                                   Function = 489
                                End Function
                                 
                                Function PBMain
                                   
                                   Local IntFunc As Dword
                                   Local Result  As Dword
                                   
                                   IntFunc = CodePtr(test)
                                   
                                   ? Format$(test),, "external"
                                   
                                   !  call IntFunc
                                   !  mov Result, eax
                                   
                                   ? Format$(Result),, "internal"
                                 
                                End Function
                                Dll Code Here...

                                Code:
                                #Compile Dll
                                #Dim All
                                 
                                Function test Alias "test" Export As Dword
                                   Function = 12345
                                End Function
                                Scott Slater
                                Summit Computer Networks, Inc.
                                www.summitcn.com

                                Comment


                                • #17
                                  >You can call both functions this way...

                                  I think you should send that in to Modern Programmer magazine as your candidate for this years' "terrific coding technique" award.
                                  Michael Mattias
                                  Tal Systems Inc. (retired)
                                  Racine WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    Ok I will submit to the part of "It can be confusing and hard to troubleshoot." Because when I do run into a function I made up and it just happens to be just like another function of the same name (different params) I will get the duplicate function error.

                                    What would be nice is if instead of just showing me the duplicate function. ALSO show me where the other function is.... (In larger projects I waste a TON of time looking for where this duplicate is???? (Usually I just rename the duplicate I do know (but maddening when I can not thing of a name to not conflict with another possible name))

                                    That said, my original idea was so obscure, that I had to try it to achieve a solution to a problem. But when it worked, my Gibbs-Gut knew it was right, but was too close of a tightrope to know if it was safe? or if I was just lucking-out until some future crash????

                                    Now some very useful points have come into play with "How I understand the Doc's" so I thought I would post an example to try to get us all on the same page.


                                    This should either prove me right or wrong as to the "Magic" of why it "Just Works!!!!"

                                    From Scott Slater's Example (No API's Involved just home grown DLL and EXE)
                                    Code:
                                    #COMPILE EXE
                                    #DIM ALL
                                    #INCLUDE "Win32Api.inc"
                                    
                                    DECLARE FUNCTION test LIB "TestDll.dll" ALIAS "test" AS DWORD
                                    
                                    FUNCTION test AS DWORD
                                       FUNCTION = 489
                                    END FUNCTION
                                    
                                    FUNCTION PBMAIN () AS LONG
                                         LOCAL LocalFunction AS LONG
                                         LOCAL LocalFunctionReply AS LONG
                                         LOCAL RealFunction AS DWORD
                                         LOCAL RealFunctionReply AS LONG
                                    '*** Local Functions
                                         LocalFunction = CODEPTR(Test)
                                         LocalFunctionReply = Test
                                    '*** Remote Functions
                                         RealFunction = GetProcAddress(GetModuleHandle("TestDll.dll") , "test")           'Get Function (if exists)
                                         SELECT CASE RealFunction                                                             'Check if Function is loaded
                                              CASE 0                                                                          'Not Loaded
                                                   LoadLibrary "TestDll.dll"                                                 'Load necessary dll
                                                   RealFunction = GetProcAddress(GetModuleHandle("TestDll.dll") , "test") 'Get Function (if exists)
                                              CASE ELSE                                                                       'Loaded
                                         END SELECT
                                         IF RealFunction = 0 THEN EXIT FUNCTION                                               'If still not loaded then exit
                                         CALL DWORD RealFunction USING GetLastError() TO RealFunctionReply
                                         FUNCTION = RealFunctionReply                                                         'Return Reply
                                    MSGBOX STRING$(20, "*") + "   F r o m   E X E   M O D U L E   " + STRING$(20, "*") + $CR _
                                              + "ModuleHandle = " + STR$(GetModuleHandle(BYVAL %NULL)) + $CR _
                                                   + SPACE$(5) + "LocalFunction = " + STR$(LocalFunction) + $CR _
                                                        + SPACE$(5) + SPACE$(5) + "LocalFunctionReply = " + STR$(LocalFunctionReply) + $CR _
                                              + $CR + $CR _
                                         + STRING$(20, "*") + "   F r o m   D L L   M O D U L E   " + STRING$(20, "*") + $CR _
                                              + "ModuleHandle = " + STR$(GetModuleHandle("TestDll.dll")) + $CR _
                                                   + SPACE$(5) + "RealFunction = " + STR$(RealFunction) + $CR _
                                                        + SPACE$(5) + SPACE$(5) + "RealFunctionReply = " + STR$(RealFunctionReply)
                                    END FUNCTION
                                    Which in essence is what Scott wrote (just no ASM code)
                                    The Dll
                                    Code:
                                    #Compile Dll
                                    #Dim All
                                     
                                    Function test Alias "test" Export As Dword
                                       Function = 12345
                                    Now I am with Jeff as far as
                                    I must admit that I'm confused. Perhaps I'm not understanding the semantics of the word "module". If I declare a function in a DLL in my code, I am importing that function into my current process space. I'm not sure what the difference between module and process is apparently.
                                    Until I tripped on this whole idea I could not get the "MODULE" vs "PROCESS" myself (and maybe I still don't but my post earlier where I said
                                    "Module" (aka: the same function in a different DLL such as "USER32" or "KERNEL32" which they would be different "MODULE's")
                                    This Test code should show Why I think the way I think.

                                    That said....
                                    Does it work??? ..... Yes
                                    Does PB say its NOT a bug??? ..... Yes
                                    Does it have a purpose??? ..... Yes (but could be hard to debug)
                                    Should it be used??? ..... Not Generally, the whole concept can be like treading on thin ice..... just cause it serves its purpose in this case does not mean the ice will not break if not thick enough

                                    I will bow to MCM's general warnings as to why it should NOT be used for general purposes because like Jeff said "The situation could be a debugging headache" but for my purposes its like lighting a back-fire to burn out an out of control fire (minimize damage) sort of thing


                                    End Function
                                    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? "

                                    Comment


                                    • #19
                                      Cliff, the problem really has nothing to do with a module or process.

                                      The problem is, the compiler permits an ambiguous definition of a procedure name at compile time.

                                      Apparently it's not ambiguous to the compiler, it just picks the one it likes best.
                                      Michael Mattias
                                      Tal Systems Inc. (retired)
                                      Racine WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment

                                      Working...
                                      X