Announcement

Collapse
No announcement yet.

Problem with Standard Windows Kernel DLL - Please Help

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

  • Problem with Standard Windows Kernel DLL - Please Help

    I am trying to parse an INI (configuration) file under Windows XP from an EFS file (see attached).
    The DLL is supposed to set an (output) parameter (aside of returning a value).
    This does not work as i expect it to.
    The DLL call DOES return a value but the output parameter is not set.

    Can anybody shed a light on this?

    Thanks,

    Bey
    Attached Files

  • #2
    You're expecting a Javascript variable, passed into a DLL call to get filled in on the C-side of the call as though it is equivalent to a pointer to (or starting address of) a character array (in C Language terms). It's not.

    eSignal's DLL interface can only handle retrieving the return value. They don't handle marshaling of parameter values so that information can get returned back into them from a DLL call.

    You can only rely on the return types that eSignal supports in their DLL Object call interface.

    Comment


    • #3
      Parsing INI DLL

      Thanks Steve.
      I guess the solution is to write my own DLL (say in VB6, or whatever language besides kludgy EFS) that does have a facility to get an output parameter which it will return as the result of the DLL.
      The output (return value) should be either the actual string from the INI file (when the call is successful) or some "standard" error string when the call is unsuccessful.

      Comment


      • #4
        If this is a real .ini file (not a registry equivalent?) then maybe easier just to use the File object and write code to parse the file?

        Comment


        • #5
          Problem with Standard Windows Kernel DLL

          Dave180,
          I guess you can write code to parse a configuration (.ini) file but the whole purpose of having kernel dll(s) is to avoid this mess and provide a consistent interface and predictable behavior.
          If you read the previous contributor to this thread, the real issue is that eSignal has no provision for maintaining memory in a way that enable passing of output parameter(s) into DLL's.

          Aside of this, are you aware of the fact that each person on this thread just got about 8 copies of your response?

          Not sure how / why it happened but, it did.

          Bey

          Comment


          • #6
            Sorry about the multiple replies, I see only one post in the thread, but, as is often the case, I often find that the forum technology does not come back with the normal "message posted" or whatever response when I first hit the "submit" button - something I have mentioned in the past but it never seems to get better - and yes I also get multiple copies of other posts, so I guess others see the same problem.

            As for the ".. is to avoid this mess ... real issue is that eSignal has no provision ...." I've pretty much given up posting comments about what is wrong with, and thus what eSignal might do to improve, the product as I've noticed that they no longer provide the same level of support as we used to get a year or two ago, and anyway as they push so many versions with so little regression testing they obviously don't have the time to actually fix or improve, so I no longer waste my time bothering to properly document and post the issues. Hence, as a pragmatist, I thought you might like the work around - or you could just wait.

            Here's hoping this post works just once.

            Dave

            Comment

            Working...
            X