Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Tue Nov 21, 2017 3:47 pm

All times are UTC - 7 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Wed Aug 31, 2011 5:54 pm 
Offline

Joined: Wed Aug 31, 2011 4:59 pm
Posts: 3
Hi,

I have early Qlarity code running on a G58. The app contains multiple screens, each implemented at the top level of the object hierarchy. A SoftKeyBarV2 instance defines one soft key per screen, and each soft key implements handleKeyPress() to enable its corresponding screen via _ShowScreen(). This works fine.

The code also implements a user message, UMSG_RECORD_RECEIVED, that is sent from a BasicSerialV2 instance's datareceived() handler each time a complete record has been received. The send is accomplished by calling UserSendMsg(default, UMSG_RECORD_RECEIVED, 0, true), and the record is stored in a global variable. This is also working as expected.

A RecordLabel template derived from LabelV2 is my test template for a future group of "record aware" templates that the app will ultimately use. RecordLabel implements a UMSG_RECORD_RECEIVED handler and simply updates its value to reflect new records as they are received. This works fine, with one exception.

The problem is record aware objects not on the currently active screen do not receive the user message. This seems expected behavior based on documentation for _ShowScreen() and UserSendMsg(), but isn't correct for this application. I could broadcast the message, but this seems overkill. Is there another solution to ensure that objects not currently enabled receive a user message? Or, a way to keep the objects and their parents enabled so that they receive a message while still getting the correct output on the display?

Thanks!


Top
 Profile  
 
PostPosted: Thu Sep 01, 2011 8:30 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Based on the architecture you have outlined, UserBroadcastMsg is probably your best bet. Objects that don't handle UMSG_RECORD_RECEIVED get skipped during the broadcast, so it is more efficient than you might think -- just a quick traversal of the object tree and for objects that handle the message a Qlarity function call.

The other approach that works here is a bit more work -- basically you create a global array of type RecordLabel. In each RecordLabel's MSG_INIT handler you append the "me" objref to that array. This provides a global list of all RecordLabel objects, you can then iterate over and directly invoke functions. The primary advantage to this second method is that you can invoke any function and are not constrained to the function signature mandated by a User message.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Sep 01, 2011 10:11 am 
Offline

Joined: Wed Aug 31, 2011 4:59 pm
Posts: 3
Jeremy wrote:
Based on the architecture you have outlined, UserBroadcastMsg is probably your best bet. Objects that don't handle UMSG_RECORD_RECEIVED get skipped during the broadcast, so it is more efficient than you might think -- just a quick traversal of the object tree and for objects that handle the message a Qlarity function call.


Looks like I discounted this approach too quickly. Let's say the app has 1000 objects and it's acceptable for each call to UserBroadcastMsg to consume 100 msec of time, not counting execution of the message handlers it matches. That's an object scan rate of 10,000 obj/sec. Is this reasonable for a G58?

Thanks for the quick and thoughtful reply.


Top
 Profile  
 
PostPosted: Thu Sep 01, 2011 10:34 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Well, I can honestly say I have never tried to profile that particular scenario, so I cannot say whether those numbers you have are reasonable (although they probably aren't highly unreasonable either). You can use GetProfileTick to measure that type of information for your scenario.

I don't know that your hypothetical UserSendMsgToAllEnabledObjectsEvenIfTheParentIsDiabled function would be significantly faster, either way the entire object tree must be traversed (The firmware doesn't have some sort of seperate list of all enabled objects), and in practice 90%+ of the objects in a workspace are probably enabled (you generally just disable screen-type objects, the children on the screen remain enabled most of the time).

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Sep 01, 2011 4:30 pm 
Offline

Joined: Wed Aug 31, 2011 4:59 pm
Posts: 3
Jeremy wrote:
I don't know that your hypothetical UserSendMsgToAllEnabledObjectsEvenIfTheParentIsDiabled function would be significantly faster...


Ah, so Qlarity doesn't maintain separate lists of registered object-func's for each message...? So it's either broadcast, or another dispatch mechanism that can maintain knowledge of the specific objects that need to be signalled. If broadcast looks to become a problem, I'll just do a "compile time" dispatch with a global function that hard-codes a func call to each object that needs to know when a new record arrives.

Thanks again for the great info. I'm finding it an enjoyable experience, becoming acquainted with Qlarity.


Top
 Profile  
 
PostPosted: Tue Sep 06, 2011 7:01 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Internally Qlarity has registration lists for a few "sparse" messages -- such as MSG_COMM_RECEIVE and a few others (basically ones you have to call RegisterMsgHandler on). This does not include user-defined messages though. UserSendMsg and UserBroadcastMsg require tree traversal. UserDirectMsg does not -- it goes directly to the target object.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 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