Replies: 5 comments 16 replies
-
Yes, I think that sounds good. The approach @tomstix is going for makes a base class for a VT interface and derives from that a server and client, which is also a fine approach if there's a lot of common code. If not using that approach, it might be good to still re-use some of the enumerations in the client if possible just to minimize duplication, perhaps by putting those in their own header file and nested namespace? I think we'll want some send_* methods to be private (or protected), and for the class to automatically respond to some client messages based on settings that can be configured in the public interface. For example:
But many things will need to be public, such as a method that can be called when a button is pressed, held, or released so that the interface can send the appropriate messages, and ways to register for events from a client, such as when they change an attribute, change a number value, change a string value, etc. |
Beta Was this translation helpful? Give feedback.
-
Ok, I'm going with the base class approach for now. In case somebody is interested, you can see the current state at my forked repo. Although I just realized that I'm working in the vt_server_managed_working_set branch. Should have made a new branch for this. At the moment, there is only the base class with enums moved from VTClient (including refactor of the vt_client_tests to match the move enums) and an empty scaffold of a server class and corresponding test file). I still need to understand more of the code structure and inner workings of isobus++, but the VTClient class is a good example |
Beta Was this translation helpful? Give feedback.
-
I am making a little progress, working towards getting the initialization with a working set master to work. I was thinking about a test setup and wondered how complete the vt client implementation is. For example, would it be feasible to connect the vt client example with my vt server implementation over a virtual can socket on linux? (This goes more in the direction of manual testing. I saw how the unit testing is done for the client, where handcrafted messages are processed. For unit testing I want to implement something similar for the vt server) |
Beta Was this translation helpful? Give feedback.
-
Minor update to this thread... I am still trying to create a VT server, and I've made a great deal of progress. I now have the majority of objects rendering properly, all the handshaking, and button/soft-key events handled. This project is taking a MASSIVE amount of effort, but the work goes on. So, of course some things are still not 100%, but the end is in sight at this point. Stay tuned, I guess, haha 🙂 |
Beta Was this translation helpful? Give feedback.
-
hi, dear friends, I have encountered some problems in the process of developing VT. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone,
I want to start a VT server implementation but I am still new to the Isobus world. Thanks to the great work of @ad3154 we have already a good base for the object tree parser in this branch. I would like to contribute to the VT server but need some guidance. I need to brush up my C++ and gain some deeper knowledge of the 17833 standard, so in the beginning my code and questions will be really basic.
Looking at the implementation of the VT client, I would create a VirtualTerminalServer class that is basically the counter-part of the VirtualTerminalClient class. So VirtualTerminalServer would abstract the communication and present an higher-level interface (with send_* methods and the possibility to register event listeners). Is this a valid approach? Also I would like to hear any other advice you might have.
Thanks to everyone contributing to this library. I am happy to see an open source Isobus library with such a high code quality :)
Beta Was this translation helpful? Give feedback.
All reactions