Loading ...
Sorry, an error occurred while loading the content.

Passing uchar (bytes) to DLL's

Expand Messages
  • mike_collins_23
    Hi, I need to pass 3 uchar s (8 bits each) to a DLL. Liberty (V4.03) doesn t seem to support passing bytes to DLL s and I can t see a way around it. Of course,
    Message 1 of 4 , Sep 18, 2007
    • 0 Attachment
      Hi, I need to pass 3 uchar's (8 bits each) to a DLL. Liberty (V4.03)
      doesn't seem to support passing bytes to DLL's and I can't see a way
      around it.

      Of course, if it had been 2 bytes or 4 bytes I don't think I would
      have had a problem. Presumably I could have combined them into a word
      or a long (after working out little/big endian etc.).

      I assume that when strings are passed as type ptr it is always the
      pointer value that is passed (not the string itself) ?

      I am not certain on this point as in message #8671 Alyce suggests
      that if the string is not null terminated then the string is passed
      (or did this mean a pointer to a copy of the string ?).

      Has anyone got around this limitation ? Any changes planned for
      future versions of Liberty Basic ?
    • Stefan Pendl
      ... There is the struct type char[] that you can use for any number of bytes. ... Stefan Pendl
      Message 2 of 4 , Sep 18, 2007
      • 0 Attachment
        >
        > Hi, I need to pass 3 uchar's (8 bits each) to a DLL. Liberty (V4.03)
        > doesn't seem to support passing bytes to DLL's and I can't see a way
        > around it.
        >

        There is the struct type "char[]" that you can use for any number of bytes.

        ---
        Stefan Pendl
      • Brian Schmalz
        I have an application that receives data via UDP from an embedded medical device. I display this data on the screen as it comes in. The way I do this is to
        Message 3 of 4 , Oct 1, 2007
        • 0 Attachment
          I have an application that receives data via UDP from an embedded
          medical device. I display this data on the screen as it comes in. The
          way I do this is to have a timer tick run every 100ms to check for new
          data, and if new data has arrived, display it on the screen.

          The way that I display it on the screen is to draw it into a memory
          device bitmap context using API calls, and then at the end of the timer
          routine, bitblt those DC bitmaps to the main window (which is defined as
          a graphics window, if it matters). The problem with this approach is
          that the bitmaps don't 'stick' to the graphics window, because they are
          not actually in LB's graphics draw commands. So I do a GETBMP of the
          whole window and then a PUTBMP to get it to stick.

          This actually works really wonderfully (although it consumes extremely
          large amounts of memory - but I can work around that) until there is
          another window (from LB or another application) that you put in front of
          the graphics window as it is being refreshed by the timer routine. When
          the GETBMP call occurs, it actually gets part of the other app's window
          that is in front, and then this gets 'stuck' to the LB graphics window
          by the PUTBMP command.

          How do I get around this? How do I tell LB that the GETBMP command is
          not supposed to grab data from the actual 'screen', but rather the
          bitmap that's part of the graphics window's DC?

          *Brian
        • Stefan Pendl
          ... GETBMP is a screen dump, you can force the window on top of all windows before using GETBMP. See the SetWindowPos API function. ... Stefan Pendl
          Message 4 of 4 , Oct 1, 2007
          • 0 Attachment
            >
            > This actually works really wonderfully (although it consumes extremely
            > large amounts of memory - but I can work around that) until there is
            > another window (from LB or another application) that you put
            > in front of
            > the graphics window as it is being refreshed by the timer
            > routine. When
            > the GETBMP call occurs, it actually gets part of the other
            > app's window
            > that is in front, and then this gets 'stuck' to the LB graphics window
            > by the PUTBMP command.
            >
            > How do I get around this? How do I tell LB that the GETBMP command is
            > not supposed to grab data from the actual 'screen', but rather the
            > bitmap that's part of the graphics window's DC?
            >

            GETBMP is a screen dump, you can force the window on top of all windows
            before using GETBMP.
            See the SetWindowPos API function.

            ---
            Stefan Pendl
          Your message has been successfully submitted and would be delivered to recipients shortly.