Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Thu May 23, 2019 5:48 am

All times are UTC - 7 hours

Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Fri Jan 26, 2007 2:27 pm 
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I suspect that this is just the tip of the iceberg when it comes to the Qlarity rendering engine, but I wanted to share a couple of thoughts.

This particular scenario is very difficult for customers to code around:

The application is about to perform a time intensive operation and needs to inform the user to expect a delay, perhaps by setting a label's caption, before it begins the operation.

The user has to perform the following steps:

    * Create a custom user message.

    * Set the label's caption.

    * Override the label's Draw() function (assuming that the object he is using has an overridable Draw).

    * In the overriden draw, post a UserDirectMsg somewhere indicating that the draw has completed

    * Handle the custom user message and perform the operation

From a usage standpoint this is a real pain. From a tech support standpoint, this is a pain to describe to even moderately bright users.

At an absolute minimum, we should an API which will force any pending draw messages to complete before it returns. (From a technical standpoint, this shouldn't be much more difficult than the current UserSendMsg API with DoNow set to true).


Some other things that would be nice from an object design standpoint:

    * An option for an object to not have to start from scratch when it draws (i.e. when MSG_DRAW is called, it already has the results of its last draw in tact, so the object could only draw changes)

    * The ability to "erase" portions of an object during a MSG_DRAW. In effect to opaquely draw the transparent color over the object.

    * Some sort of ability to draw directly to a canvas or a pixmap. We have this very crudely in place with the MSG_DRAW_TO_PIXMAP, but that has a number of limitations (such as cannot be done during a MSG_DRAW).

    * The ability to scale pixmaps & bitmaps

    * For drawing purposes, it might be nice if Area Object's origin were (0,0) instead of (xPos, yPos) -- Ron, do you have some feedback here? Would it be confusing if the object used it's parent's coordinates for placement, and its own zero based coordinates for drawing? Containers already do this.

    * DrawBox (and other APIs) would take a width and height instead of a right and bottom. This is easier for objects, which already track their width and height, but don't usually track their right and bottom position.

Edit 29 Jan: Fixed formatting. Added DrawBox suggestion to suggestions list


 Post subject:
PostPosted: Tue Jan 30, 2007 11:00 am 
User avatar

Joined: Thu Mar 02, 2006 2:12 pm
Posts: 487
Location: Salt Lake City, Utah
Yes, its confusing for an internal objects drawing code to not start from 0,0. I also prefer using Width & Height VS. Right and Bottom.

Ron L.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 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:  
Powered by phpBB® Forum Software © phpBB Group