No announcement yet.

OCX file support

  • Filter
  • Time
  • Show
Clear All
new posts

    OCX file support

    Hi all,
    I'm looking at buying a USB I/O module that can control LEDs, relays, and the like. It comes with (from their website):

    "An OCX so that you can control it from your own applications, and code examples for VB6"

    I'm not sure what an OCX is, it appears to be similar to a DLL.

    Therefore, the question is, can OCX files be used by PB8, or are they a Visual Basic thing only?

    Thanks in advance to anyone that can help us with this one.


    What company? I use Measurement Computing modules with no problems and a minor re-write of their VB include file. The only time it's more difficult is if the company supplies only a *visual* ActiveX component, and you can even use that with a few more lines of code. If you can download their software package, you may be able to use the PB Com Browser to examine the driver.

    If the device is based on the FTDI USB chip set, that works well with PB too.


      The URL of the company that makes the module:

      They are dirt cheap (under $50).

      I don't know if the OCX they supply is a visual one or not, and they only supply the software with the item, it's not downloadable separately.

      I've emailed them and asked for a bit of VB6 source before I pull out the credit card.

      Thanks for the reply,


        It looks like they may have rolled their own, rather than using the FTDI chip, but I'd be amazed if PB had any problem with it. I've yet to find anything I can't interface too, and I'm not all that sophisticated a programmer.


          Alternative board

          Search the posts for Velleman K8055 - comes with a good DLL (written in PB I believe) and at a good price.

          Iain Johnstone
          “None but those who have experienced them can conceive of the enticements of science” - Mary Shelley


            Hi Conrad,
            I heard back from them, it looks like the OCX is a "visual" one, which makes it just about useless without a lot of reverse engineering. They were very vague in their reply, but from what I could gather they only show how to call their interface, not be able to make your own. They also made it very clear that I'd have to buy some first and get the source later

            I decided to give them a miss and look at designing my own later.
            Thanks for the reply.



              Hi Iain,
              Thanks for that - had a quick look, at least it has source available, I was hoping to buy local though. I'll look a bit closer at them and find a cost with postage to Oz.

              Thanks for the reply.


                If you want inexpensive... works with PB.


                  Using VB6 and/or VB.NET, is it possible to make a .dll that would act as a proxy between PB and a recalcitrant .ocx?
                  Erich Schulman (KT4VOL/KTN4CA)
                  Go Big Orange


                    Chris, the company I do a lot of work for only supplies a visual interface for their products. Using a wrapper from Jose Rica's site, it's no big deal to work with a visual interface. I call the routines and they come up just as they would in VB. I'd say the additional code is about three or so lines- even my minimal sized brain can deal with it.

                    Still, I really like the Measurement Computing modules, if they have a cheap one that has the features you need. I bought a 1024HS (I think?) for my home lab for about $150 as it's nice for running steppers and relays in conjunction with my HPIB test equipment. For an analog interface, I don't bother with specialized"interface" boards. I just buy clean used HPIB voltmeters and get the best of all worlds using the Prologix HPIB converter (about $150). As an example, you can pick up an old HP 3455A 6 1/2 digit voltmeter that will hold about 5 parts per million calibration nearly forever, for a couple hundred max. The only downside is size. There are also very capable 5 1/2 digit benchtop meters in small cases like the HP 3478A. Not sure what you want to do, but there are lots of ways to control things using PBWin.


                      it's nice for running steppers and relays in conjunction with my HPIB test
                      You mean Stepper motors? (We need to talk )
                      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? "


                        I need to write a functioning demo in PBWin for running stepper motors like I used to with PB 3.5 for DOS. In concept you just need some kind of parallel output like what you showed, the Measurement Computing module, or any other similar gadget. You set up a variable which contains a binary word representing the winding states. All that's required to rotate the motor CW or CCW is to shift the data left or right and send it out the port. It takes longer to describe than to code. If the port is any good, you can rotate the data, and thus the motor, far faster than most motors can go.

                        Recently at work I started playing with a Peter Norberg motor controller. These are in the $100 range, but are USB ready with the FTDI chip. They take simple ascii commands or you can use the DLL (not sure why to bother), and they keep track of motor location for a huge number of revolutions. I was pretty impressed with the thing, especially its microstepping capability.


                          >They take simple ascii commands or you can use the DLL (not sure why to bother),

                          DLLs in general are a nice way to package things for ease of maintenenace or upgrade. Eg, you might want to create "Nice User Interface for XXXXX brand model 1234 motors."

                          You can then update that interface without touching the actual motor code... or possibly upgrade your interface without any code changes for a different model by doing exactly NOTHING other than changing the DLL which handles all the direct device interaction.

                          eg, if the ASCII command is "JOG 12 L" for one model, it might be "JOG 12 L X" for the new model.... but if you do your code correctly, you could use the same CALL or CALL DWORD line in your interface code regardless of model (and machine DLL) in use.

                          I do this now in both the Provider Payment Partner(tm) System and the EDI PAL ANSI ASC X12 Viewer-Editor-Printer. Both products handle different input data formats, but use exactly the same user interface code. If you have installed (aka "purchased a license for") the DLL for a particular format, it works. If you haven't, it doesn't.

                          In PPPS it goes one step further: you can order a custom query or report. That functionality is packaged in a DLL. You install the DLL, it looks like part of the system... but the best part is (from the user perspective) you can upgrade the main program and not have to 're-modify' it to support your particular tailored features.

                          A little bit more work to set up, but IMO well worth it in my market.

                          The Provider Payment Partner System
                          (He shamelessly posted).
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]