DesktopX 2.4 Developer’s Guide
_____________________________________________________________________________
_____________________________________________________________________________
Page 37
4.8 Meter objects
Be aware when building objects that show and update information (i.e. using the DXPerf4 plugin
or browsing information from the internet or checking the mail with the mail notify plugin).
Too frequent updates of many objects at the same time could cause slow downs, so it is very
important to tune every information object carefully. I.e. you don’t want a disk space meter
object to update every 200 ms!! Also most other meters (CPU, network traffic, etc) should just
work fine with an update interval great than 600 ms.
4.9 Writing “proper” scripts
Using the DXScript facility combined with the VBScript simplicity is great and powerful, but be
aware to avoid writing “poor” script. It is very easy to build in subtle mistakes that will then
cause serious stability and performance problems.
The two most common mistakes are:
You instantiate an object and you do not release it afterwards. This will cause a memory leak.
You use the DesktopX.Object(“foo”).property too often. If you reference the “foo” object
frequently, first create a reference to it. This will optimize the script performance, but be sure
you DELETE the reference when you don’t use it anymore (see above)!!
Always assume that attempts to access COM objects functionality may fail and build in support
for handling this. Some users could just lack certain COM objects. Also, objects using scripts to
retrieve information from the internet could not have an always-on connection, the website could
be down etc. So, you should add runtime checks to avoid script errors and continue with a clean
execution even if there are faults.
4.10 Building “proper” objects browsing the internet
Example: Weather Information objects.
These objects are the most difficult to write properly so they deserve particular attention.
You just can’t assume that a user is connected to the Internet, so browsing could fail and cause
very annoying script errors. You should ALWAYS check the connection status, and also check
about the success of browsing operations. You should assume that you can retrieve NULL or
invalid data.
Also, objects that connect to the Internet should follow a specific usage protocol to avoid
annoyances. They should keep an internal connection status that just informs the script about
“Can I try to access the Internet? YES/NO”. This is different from the actual connection status,
