I’m trying to control a complex device. The device has variable multiple objects of a similar type to set up. Each object can however be set up in several different ways. I want to display a summary of each object and a button to setup that object. I can’t easily find a way of doing this, so what I have come up with is as follows:
Use a RpRepeatGroupDynamic, containing:
RpIndexDisplay_0 "Object " - which displays Object x where x is the index number for that line
Then a RpFormVariableSelect Dynamic which lets me select which type of mode to setup the object up in.
Then
.htm> to create a link to pages object_1.htm object_2.htm etc.
I would then like it to work out that I’m updating object 1, so find out what type that object is supposed to be from the RpFormVariableSelect and jump to PgTypexyz instead. Is there a way of trapping HTTP 404 errors or similar to achieve this, or do I do it with 50 different object_x.htm pages with a RpPageHeader=doObjectx code that does the redirection?
I hope that makes sense…
Or is there a much simpler way of doing this?
Cheers,
Simon
In my opinion, the answer is “it depends”.
Part of your statement is as follows:
" I want to display a summary of each object and a button to setup that object." This tells me that you want to allow the user to “update” device data (the object), which means that you want a “stub function” associated with a web page to fire. Generally that would have to be done with a bunch of html files that have their own RpGetPtr and RpSetPtr attributes associated to stub functions. Those html files would be run through the PBuilder utility to generate the function prototypes.
If you were just displaying data, you could generate the web pages to go back to the browser, “on the fly” by writing the html code to the file system and then using page control to point (redirect) to that page (that html file on the file system).
About the only other thing that comes to mind might be to use AJAX methods to get back data from the device and then use some fancy javascript to build pages.
The way you describe might also do it.
Clearly the easiest is to set up an html page for each object type have code for that device do whatever needs to be done. My assumption is that a lot of the actual device(object) interactions are similar that you should be able to have a lot of common code and therefore reduce the amount of code you actually have to write.
I always take a deep breath when global variables are mentioned. They can have their place. What I would advise is that you test with multiple web browsers simultaneously (using a couple of PCs). I think that all of the stub functions for one page/connection will be executed before the web server moves onto another connection. But I’d verify that before getting in too deep.
Thank you, sparkys_dad.
The issue with what you suggested is that some of the objects can be the same. ie I can have objects 1 and 2 being apples, 3 and 4 being oranges and 5 being a banana. Apples, oranges and bananas all need different setup parameters and there would be a apple.htm page for that purpose, but when they have selected apple in the object type dropdown and click the button next to it I want that button click to go to apple.htm with the information that it’s for object 1, rather than object 2.
I seem to have sussed this while cheating very slightly. In my RpRepeatGroupDynamic I have a RpFormVariableSelect with keyword Dynamic set. This control comes before the button. When the stub function is called for this control it saves the index number it was called with in a global variable. When it calls the RpFormNamedSubmit stub function to populate the name of the button it adds this index number into the name. When the button is pressed the ‘set’ stub function copies this button string back into another global variable that is picked up by the formsubmit stub function to redirect to the correct page with suitable attributes.
It’s cheating because I am relying on the fact that the control stub functions are called in the order that they appear on the web page, ie my FormVariableSelect stub will ALWAYS be called before the FormNamedSubmit stub function so that the index value can be saved.
I’m doing my best to avoid AJAX type methods and too much javascript but I suspect we’ll end up using something like that one day when it all gets too complicated.
Cheers,
Simon