Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Wed Nov 22, 2017 5:38 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Hiding Object Properties
PostPosted: Wed Jun 03, 2009 8:52 am 
Offline

Joined: Wed Jun 03, 2009 8:47 am
Posts: 6
I'm currently trying to make some lightweight components for the rest of my company. I'm the engineer on this project and they want to be able to easily customize components. Since we only use certain hardware, most of the object properties can be standard. I was wondering if there is anyway to hide certain object properties that will be standard for our components. I have created a new template for my components and have even tried to modify libraries (will some trouble) to hide certain object properties. Any help would be much appreciated. Also, is there any documentation on all of the #XXX commands that can be compiled by Qlarity?


Top
 Profile  
 
PostPosted: Wed Jun 03, 2009 9:02 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
If you really don't want someone changing the property of an object you have a couple of fairly straightforward possibilities.

The first, is to inherit off of the base template and redefine the properties you don't want changed as private. The derrived template definition will hide the base template definition.

For instance, if you wanted all ButtonV2 objects to have a bright red background, you could easily define a new template which extends ButtonV2 with this definition

Code:
private dim bgColor as colormap%
init bgColor := 224

This will override the default property declaration as well as make the background color red. Because the new declaration is private it will not appear in the properties window.

Another option would be to use the #hidden directive (#hidden is an older directive that predates inheritance or even private. We rarely use it anymore).

Again, using inheritance you can do this

Code:
#hidden dim bgColor as colormap%
init bgColor := 224


This leaves bgColor as a public property, but prevents it from appearing in the properties window.

If possible, I would encourage you to use inheritance. You can, of course make these modifications directly to the libraries and not use inheritance. The major drawback is that if you ever upgrade Qlarity Foundry, your changes will be replaced with the latest version of the system libraries.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Wed Jun 03, 2009 9:04 am 
Offline

Joined: Wed Jun 03, 2009 8:47 am
Posts: 6
I would still like to know the different #xxx commands though. Can you help me out? I'm running Qlarity 2.5 on a G55.


Top
 Profile  
 
PostPosted: Wed Jun 03, 2009 9:33 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I don't know that they are all documented in one place. They are not preprocessor directives like C/C++ has, they are usually metaflags that have little to no meaning to the compiler but are used by Qlarity Foundry. Here they are and where they are documented (in the programmers reference unless otherwise noted)

#if, #ifnot, #else, #endif---2.21
#option---2.21.2
#Begin_Advanced_Code (Undocumented, Qlarity Foundry source flow directive)
#End_Advanced_Code (Undocumented, Qlarity Foundry source flow directive)
#stpbuilderapp---2.21.8
#setfile---2.21.5
#toolimage---2.21.3
#visible---2.21.6
#endfile---2.21.9
#lock ---2.21.7
#hide---(Undocumented -- line will be processed by the compiler, but discarded by QF when loading the file)
#hidden---2.21.4
#NullToken (Undocumented, used for testing)
#config---(Undocumented, various Qlarity Foundry workspace meta-information that is not needed by the compiler)

Many of the #flags are related to the fact that a .qly file is both a Qlarity Foundry workspace and a valid input to the command line compiler. Qlarity Foundry needs to keep track of various pieces of information that is relevant to it but not to the compiler. In one case (#hide) QF needs to emit lines needed for the workspace to properly compile but QF itself doesn't need the lines (it can infer it from other workspace information)

Of the listed commands, only the #if family, #option and #hidden would ever be directly used by programmers. The remaining ones may appear in a .qly file and you may wish to know that they do, but there is no real reason to ever directly use them.

There are also another family of # "commands" related to the autodocumentation facility in Qlarity Foundry. These are documented in Appendix B of the Qlarity Foundry User Manual. These include
#stylemap
#colormap
#flags
#category
#item
#param
#link
#importdoc
#doc
#undoc
#defaultitem

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Wed Jun 03, 2009 9:42 am 
Offline

Joined: Wed Jun 03, 2009 8:47 am
Posts: 6
Thanks for your help! I kind of thought you would give me sometime to mess around but I guess I have to get back to programming now. Thanks again.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group