My sincere apologies James for not responding sooner. Apparently I missed the notification about your post somehow.
In case it's still a problem or anyone else has this issue, any DLLs should preferably be placed in the same directory so Windows can find them all and not experience version conflict. The best place is the install directory, which depends on your LabVIEW version but looks something like
C:\Program Files\National Instruments\Labview 20XX\vi.lib\addons\zeromq
All recent releases of labview-zmq include the windows DLLs already and will get put in the above location when you install the package (inc both 32 and 64-bit versions) to avoid this problem. However, if you need to replace the DLLs for any reason that is where you'll find them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whatever it was, the latest version is working for me now.
BTW, have you considered using simple LVOOP classes for your connections and sockets? Currently you just have bare U64 integers. Classes would give them type safety and unique wire appearance.
— James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made some changes to how DLLs are handled since last year, and that should reduce installation problems. DLL hell is appropriately named.
I had considered LVOOP, but beyond type-safety and coloured wires I didn't see any advantage. Type safety can also be achieved through ref-casting, which I was considering, but initially the design was for as simple as possible and there's no real incentive for OOP since there is no inheritance. Regardless I shall reconsider in the next major revision since it'll break back-compatibility.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Type safety through LVOOP would be cleaner and simpler than reference casting. And different coloured wires is great for readability. I used LVOOP in a similar dll-wrapping task last year and it worked well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
How do I go about getting libzmq.dll installed in a place where labview-zmq can find it?
— James
My sincere apologies James for not responding sooner. Apparently I missed the notification about your post somehow.
In case it's still a problem or anyone else has this issue, any DLLs should preferably be placed in the same directory so Windows can find them all and not experience version conflict. The best place is the install directory, which depends on your LabVIEW version but looks something like
C:\Program Files\National Instruments\Labview 20XX\vi.lib\addons\zeromq
All recent releases of labview-zmq include the windows DLLs already and will get put in the above location when you install the package (inc both 32 and 64-bit versions) to avoid this problem. However, if you need to replace the DLLs for any reason that is where you'll find them.
Whatever it was, the latest version is working for me now.
BTW, have you considered using simple LVOOP classes for your connections and sockets? Currently you just have bare U64 integers. Classes would give them type safety and unique wire appearance.
— James
I made some changes to how DLLs are handled since last year, and that should reduce installation problems. DLL hell is appropriately named.
I had considered LVOOP, but beyond type-safety and coloured wires I didn't see any advantage. Type safety can also be achieved through ref-casting, which I was considering, but initially the design was for as simple as possible and there's no real incentive for OOP since there is no inheritance. Regardless I shall reconsider in the next major revision since it'll break back-compatibility.
Type safety through LVOOP would be cleaner and simpler than reference casting. And different coloured wires is great for readability. I used LVOOP in a similar dll-wrapping task last year and it worked well.