D
DBS
Short: I'm trying to create an ASP.Net application that has to
communicate with a VB6 ocx.
Info: Microsoft POS for .NET (MSPOS) is a "universal" interface for
talking to various types of hardware associated with cash registers.
It provides one interface for me to communicate with and it handles
talking to the hardware divers; allowing me to make one interface that
works on many devices. Some of these devices provide VB6 ocxs which
MSPOS supports.
Long: I have written a DLL in C# to sit on top of MSPOS to make it
easier for other developers in my company to access the functionality
(MSPOS's interface is quite large). One of the devices we use, a
display, is not supported in MSPOS so I drive it directly in my DLL.
The display has a VB6 ocx interface which I am hosting on a 'dead'
form in my DLL (just never displayed). When using a standard forms
application to talk to my DLL everything work beautifully. When the
ASP application accesses the DLL it's met with varying levels of
success.
What I've done:
1st: Before I found out that .Net didn't like com I just instantiated
everything as normal, the ASP app would crash when trying to access
the display. I subsequently discovered the joy that is STA/MTA.
2nd: In the ASP app I created a STA thread which maintains the display
objects. This mostly worked but required a restart of the app at the
end of the transaction. The display is on the same physical piece of
hardware as another device we use (driven by MSPOS) and likely has a
common com DLL at the hardware level below the ocx I'm using and below
MSPOS. When the 2nd transaction would come in opening the other
device would fail.
3rd: I tried completely closing my display thread after each trans and
reopening on the next one. This would consistently fail to open on
the second run. I tried a number of things to get it to release the
com stuff from memory but nothing but restarting the whole app would
clear it. (After talking to one of the senior guys in the company I
discovered that when dealing with com/interop disposal isn't always
reliable)
4th(current state): I am attempting to move all the hardware devices
into the STA thread inside the ASP app so they all will always be
accessed by the same thread for the life of the app. Currently I am
testing with only one logical device (driven by MSPOS). I have 2
different physical devices, one has a true MSPOS driver (made in .Net)
and the other uses the MSPOS VB6 legacy interface. The .Net device
works perfectly. The ocx device is responding to commands but does
not fire back events as it should. The hardware acknowledges my input
(it beeps) but no event is fired.
In between each of these steps I've spent long hours trolling MSDN and
Google and am now at a dead end. The only place I can think to go to
from here is to create a completely separate app out of ASP that would
service the HW. Or to drop MSPOS from this device and drive the
device directly, not guaranteed to work and deviating from the
universal 'write once' interface. Obviously neither of these are
good options.
Any help would be GREATLY appreciated.
communicate with a VB6 ocx.
Info: Microsoft POS for .NET (MSPOS) is a "universal" interface for
talking to various types of hardware associated with cash registers.
It provides one interface for me to communicate with and it handles
talking to the hardware divers; allowing me to make one interface that
works on many devices. Some of these devices provide VB6 ocxs which
MSPOS supports.
Long: I have written a DLL in C# to sit on top of MSPOS to make it
easier for other developers in my company to access the functionality
(MSPOS's interface is quite large). One of the devices we use, a
display, is not supported in MSPOS so I drive it directly in my DLL.
The display has a VB6 ocx interface which I am hosting on a 'dead'
form in my DLL (just never displayed). When using a standard forms
application to talk to my DLL everything work beautifully. When the
ASP application accesses the DLL it's met with varying levels of
success.
What I've done:
1st: Before I found out that .Net didn't like com I just instantiated
everything as normal, the ASP app would crash when trying to access
the display. I subsequently discovered the joy that is STA/MTA.
2nd: In the ASP app I created a STA thread which maintains the display
objects. This mostly worked but required a restart of the app at the
end of the transaction. The display is on the same physical piece of
hardware as another device we use (driven by MSPOS) and likely has a
common com DLL at the hardware level below the ocx I'm using and below
MSPOS. When the 2nd transaction would come in opening the other
device would fail.
3rd: I tried completely closing my display thread after each trans and
reopening on the next one. This would consistently fail to open on
the second run. I tried a number of things to get it to release the
com stuff from memory but nothing but restarting the whole app would
clear it. (After talking to one of the senior guys in the company I
discovered that when dealing with com/interop disposal isn't always
reliable)
4th(current state): I am attempting to move all the hardware devices
into the STA thread inside the ASP app so they all will always be
accessed by the same thread for the life of the app. Currently I am
testing with only one logical device (driven by MSPOS). I have 2
different physical devices, one has a true MSPOS driver (made in .Net)
and the other uses the MSPOS VB6 legacy interface. The .Net device
works perfectly. The ocx device is responding to commands but does
not fire back events as it should. The hardware acknowledges my input
(it beeps) but no event is fired.
In between each of these steps I've spent long hours trolling MSDN and
Google and am now at a dead end. The only place I can think to go to
from here is to create a completely separate app out of ASP that would
service the HW. Or to drop MSPOS from this device and drive the
device directly, not guaranteed to work and deviating from the
universal 'write once' interface. Obviously neither of these are
good options.
Any help would be GREATLY appreciated.