by PedroR » Mon Oct 19, 2009 11:03 am
by PedroR
Mon Oct 19, 2009 11:03 am
Hi l3v3rz
Great news that your testing works
With regards to returning a string, sorry for asking the obvious but have you tested the class, by declaring the return value of "connect" as a string?
If so, what were the issues you faced, so I can be prepared in advance

?
I'd also - From my work with the Remocon DLL and the wCK protocol DLL I came to the following conclusions so far:
.. Once you open the COMM port, the thread who opened it, "owns" it and therefore no other thread can access it.
.. For me, this meant I could not mix and match code from the Remocon and the wCK dll in the same sequence of code without closing and reopening the comm port
.. To overcome this issue what I thought about doing was create a separate DLL that encapsulates the communication with the COM port.
Let's call RobobuilderCOM.
This DLL is quite simple and only implements 4 methods:
.... OpenCOMM
.... CloseCOMM
.... FlushBuffer
.... SendData
(or maybe SendDataNoReturn and SendDataReturn if we want to separate between the calls that need to wait for data to be returned and the calls that don't return any data)
On its turn, the RemoconDLL and the wCK DLL would not open the comm directly but instead would use the above interface.
This way we can share access to the comm port across different classes. We may need to implement some very basic synchronization scheme to accommodate multi threaded scenarios but I haven't gone that far (maybe using a Singleton object pattern and a semaphore).
Multi threaded scenarios are not a priority at this time.
I will try to sketch up a graph for an interface so I can better explain my findings so far.
Hi l3v3rz
Great news that your testing works
With regards to returning a string, sorry for asking the obvious but have you tested the class, by declaring the return value of "connect" as a string?
If so, what were the issues you faced, so I can be prepared in advance

?
I'd also - From my work with the Remocon DLL and the wCK protocol DLL I came to the following conclusions so far:
.. Once you open the COMM port, the thread who opened it, "owns" it and therefore no other thread can access it.
.. For me, this meant I could not mix and match code from the Remocon and the wCK dll in the same sequence of code without closing and reopening the comm port
.. To overcome this issue what I thought about doing was create a separate DLL that encapsulates the communication with the COM port.
Let's call RobobuilderCOM.
This DLL is quite simple and only implements 4 methods:
.... OpenCOMM
.... CloseCOMM
.... FlushBuffer
.... SendData
(or maybe SendDataNoReturn and SendDataReturn if we want to separate between the calls that need to wait for data to be returned and the calls that don't return any data)
On its turn, the RemoconDLL and the wCK DLL would not open the comm directly but instead would use the above interface.
This way we can share access to the comm port across different classes. We may need to implement some very basic synchronization scheme to accommodate multi threaded scenarios but I haven't gone that far (maybe using a Singleton object pattern and a semaphore).
Multi threaded scenarios are not a priority at this time.
I will try to sketch up a graph for an interface so I can better explain my findings so far.