SDK issues
Danny Campbell
Posts: 311
On an existing system, my main touch panel has the application pages on port 1. In adding the RMS pages to the TP4 file, I had changed all of the various ports to 2, except for the buttons associated with the keyboard pages that were left at port 0. In other words, I changed the RMS pages instead of mine.
I tell RMS Codecrafter where the base device and rms pages live expecting everything to be good. However, good things do not happen. I can navigate through the pages and everything is good until I go to create a meeting from the panel. I get to enter the info and press the RESERVE button. At this point, the info I entered goes blank and the panel just sits there - fat, dumb, and happy like nothing happened. Using the diagnostics, I determined that the keyboard-related information all comes from port 1 on the panel in the string events. So even though all the button presses come back as 10001:2:2 (where 2 is my system number) the Reserve button sends the "reservation.subject" and "reservation.message" information back on 10001:1:2. At this point, the DATA_EVENT in the rmsUIBase.AXI file doesn't know what to do, and the meeting never gets reserved.
If I modify the rmsMain.AXI file that I generate using codecrafter to contain the device names for both panel ports, the system works but is flaky. Instead of getting a Reservation Confirmed message on my panel 10001:2:2, it gives me a Meeting Ended message like I tried to end a meeting early. But it also creates the reservation.
A bad side-effect of doing this is that the system spits out quite a few commands to the buttons on both defined panels thinking that both contain the RMS pages. This causes any buttons that I have on my application pages to get modified with the colors from the schedule, titles on the buttons change, and buttons will become disabled or enabled based on it thinking that the buttons and pages are on both devices.
Codecrafter seems to ask for the base device and device containing the RMS pages, but then the files from the SDK don't use that information. Also, the SKD documentation is no longer correct. For example, when the module is defined for the rmsUIBase module, the document shows that a main TP as well as a reserve TP are passed (along with the device for the welcome TP). When looking at the code, the reserve TP parameter has been eliminated. It appears that they tried to account for this in the data_event, but this code does not work properly.
So, there appears to only be two solutions at this point. One is to move all of my application pages to a port other than 1. While this is not something that would kill me, it is a pain and will result in unbillable hours spent changing the panels, uploading the panels and code, and then retesting. Not a big deal for a small system, but people with small systems probably don't need RMS. For this installation, I'm looking at about 80 panels.
The second option is to modify the rmsUIBase.AXI file to make it do what I want. However, this means that at some point in the future I'll have to do it all again when version 3.2 is released. Again, not a big problem if I remember, but I may have done several projects since then and since old age is setting in, I probably won't remember what I did. Or worse, (for them), someone else will inherit the maintenance for this and be completely lost.
It sure would be good if the SDK worked like I expected it to.
Hopefully, someone will tell me of a magic parameter that I've missed that makes it all work like I want.
I tell RMS Codecrafter where the base device and rms pages live expecting everything to be good. However, good things do not happen. I can navigate through the pages and everything is good until I go to create a meeting from the panel. I get to enter the info and press the RESERVE button. At this point, the info I entered goes blank and the panel just sits there - fat, dumb, and happy like nothing happened. Using the diagnostics, I determined that the keyboard-related information all comes from port 1 on the panel in the string events. So even though all the button presses come back as 10001:2:2 (where 2 is my system number) the Reserve button sends the "reservation.subject" and "reservation.message" information back on 10001:1:2. At this point, the DATA_EVENT in the rmsUIBase.AXI file doesn't know what to do, and the meeting never gets reserved.
If I modify the rmsMain.AXI file that I generate using codecrafter to contain the device names for both panel ports, the system works but is flaky. Instead of getting a Reservation Confirmed message on my panel 10001:2:2, it gives me a Meeting Ended message like I tried to end a meeting early. But it also creates the reservation.
A bad side-effect of doing this is that the system spits out quite a few commands to the buttons on both defined panels thinking that both contain the RMS pages. This causes any buttons that I have on my application pages to get modified with the colors from the schedule, titles on the buttons change, and buttons will become disabled or enabled based on it thinking that the buttons and pages are on both devices.
Codecrafter seems to ask for the base device and device containing the RMS pages, but then the files from the SDK don't use that information. Also, the SKD documentation is no longer correct. For example, when the module is defined for the rmsUIBase module, the document shows that a main TP as well as a reserve TP are passed (along with the device for the welcome TP). When looking at the code, the reserve TP parameter has been eliminated. It appears that they tried to account for this in the data_event, but this code does not work properly.
So, there appears to only be two solutions at this point. One is to move all of my application pages to a port other than 1. While this is not something that would kill me, it is a pain and will result in unbillable hours spent changing the panels, uploading the panels and code, and then retesting. Not a big deal for a small system, but people with small systems probably don't need RMS. For this installation, I'm looking at about 80 panels.
The second option is to modify the rmsUIBase.AXI file to make it do what I want. However, this means that at some point in the future I'll have to do it all again when version 3.2 is released. Again, not a big problem if I remember, but I may have done several projects since then and since old age is setting in, I probably won't remember what I did. Or worse, (for them), someone else will inherit the maintenance for this and be completely lost.
It sure would be good if the SDK worked like I expected it to.
Hopefully, someone will tell me of a magic parameter that I've missed that makes it all work like I want.
0
Comments
However, if the module itself assumes port one is your panel port, it's just onto going to work. The module has to explicitly create a handler for port one by breaking up the device and adding a port one handler for it. If it hasn't done that internally, its not going to work if the panel is on another port.
I don't use Code Crafter, but it seems to me that is what the issue here is: it's assuming port one is the panel defined. Unless you can get at the code where the handlers are defined, you may be stuck with it.
The current RMS UI module does not account for string input from the panel above port 1. We have corrected this and added additional base panel device array parameters to the next maintenance release version which should be out soon. I would suggest that you make the changes to the RMSUIBase and the RMSUI modules that you are using. Here is the new module signature for "RMSUIMod".
MODULE_NAME='RMSUIMod' (DEV vdvRMSEngine,
DEV dvTP[],
DEV dvTP_Base[],
DEV dvTPWelcome[],
DEV dvTPWelcome_Base[],
CHAR strDefaultSubject[],
CHAR strDefaultMsg[])
Two new data events are needed in the RMSUIBase.axi:
//
// KEYBOARD STRING HANDLER for dvTP
//
DATA_EVENT[dvTP_Base]
//
// KEYBOARD STRING HANDLER for dvTPWelcome
//
DATA_EVENT[dvTPWelcome_Base]
The "String" data event handler code was moved from the original panel device arrays to these two new base device data events handlers. Also make sure the "GET_LAST" operation that gets the panel index included under each of these data events now get the index from the new arrays.
Example: nPanelIndex = GET_LAST(dvTP_Base)
I am attaching the modified RMSUIBase.axi and RMSUIMod.axs file for your convenience. Use these files at your own risk, please note that the changes included are not fully tested and publicly released modifications.
Danny