If fact, its obvious that the starlims folks went heavily out of their way to make it look and feel like a traditional programming interface. Which is nice, of course, since making it look opposite would make it that much harder to code for -- no thanks that.
So, getting back on topic, XFD Frames can do a ton of heavy lifting for you, both in designing reuse and portability. For example, instead of laying out a tab control and then coding for each tab and then having the user jump back and forth between them, you can do the same thing with frames, especially if you need to define some data that needs sharing between the figurative tabs.
| Side frame | BODY FRAME |
For example, I like to keep the design of the LIMS I am working similar to webpages for user ease of learning and use. In doing so, I tend to frame the left side into a console, like the one present in the default system. When I don't, I put it above to form a menu of navigation.
The other frame I use to revolve information. It becomes handy when you need to update or adjust links on the fly or to keep track of information handily. While starlims provides form and navigator variables for such things, I find that putting defined variables there is pretty handy and much more accessible across multiple forms when I'm revolving them through the frames. You can access them by concatenating the frame's name + form + variable. Which, if you are re-using linklabels or buttons in your navigation, writing and re-writing dynamic events (probably the best use of the sender, event args duo I have found) based on the form in the other frame becomes very useful.
Referencing is done like follows:
var Base_Form : Form = form.Parent.ParentForm.Id;
- id is the name of the base form
- ParentForm is the form that contains the frame (i.e., its parent)
- Parent is the frame
- form is the actual form
No comments:
Post a Comment