|
...Continued from Page 17.
A sample of a grid and border. |
Snapping to attention.
ProntoEdit NG includes two basic functions for centering a button or group of buttons vertically or horizontally on the page (but not in relation to each other). An on-screen grid can be toggled on or off and can be made “snap to” so that objects cling to each line. Grids are no longer set by how many pixels apart each line should be, but rather how many rows and columns there will be. So, if you’re looking for a grid with 10 by 10 pixel spacing, you’ll need to enter 24 columns by 32 rows. The maximum number of rows or columns is 45.
The final layout aid is a border, which draws a blue box around the edges of the page. A border can be specified from 1 to 40 pixels inside the page, and the snap-to grid will only activate inside of those dimensions. This is apparently to help users keep buttons away from the screen edge where they may be difficult to press, but I don’t recall that being a real issue in the past. In spite of these well intentioned aids, the most practical layout tool for power users is still the button position coordinate display in the status bar. Sometimes simple is best!
Final layout options.
Two important features in ProntoEdit NG are the ability to hide devices and individual pages. Hiding an item does not prevent access to it; however its contents can only be reached if specifically requested from another button.
The Pronto NG Emulator. |
Why would you want to hide anything? Well, one example would be a device whose purpose is only to hold learned codes. All “real” devices would alias to these codes, making it easier to update with different equipment later and, if you plan on sharing the file with others, aiding the integration of your codes with their layout. Since normal access to this device is not required or desired, hide it. A similar reason for hiding pages would be a “Help” page that should only appear if requested, not while using the scroll buttons on the side of the remote.
A final option is to make the device a “Template”. Template devices cannot be accessed on the remote, not even via an alias. The only reason for even thinking about templates is for the remote’s “Add Device” function. Without templates, it’s impossible to create new devices via the remote’s setup menu. If you only plan on making use of ProntoEdit NG to edit your file, templates are of no value to you and can safely be ignored.
If you’re designing a layout or thinking of purchasing a TSU3000 and want to get a feel for how the actual remote works, ProntoEdit NG includes a fully functional emulator that demonstrates exactly how any configuration file will look and operate – complete with a picture of the remote and functional hard buttons. The emulator no longer integrates with a connected TSU3000 for “live” code testing and learning, as the TSU2000’s emulator did.
Downloading a file. |
File shifts.
While the CCF file format of old represented the actual data as downloaded to the remote, the new PCF file format is merely an intermediary step – in fact it’s an ordinary zip file containing a single XML (text) file and multiple BMP (image) files. Whenever ProntoEdit NG emulates a layout or downloads a file to the remote, it processes the PCF file into a different format. However, it appears that the new XML file structure is nowhere near as efficient as the original binary CCF format: working with large files can take an inordinate amount of time, even with a fast computer.
For example: opening my converted ProntoPro CCF as a PCF file in ProntoEdit NG 1.2.4 takes 1 minute and 49 seconds on a Pentium 4 2.53GHz with 1 gigabyte of RAM. It takes under half a second with ProntoEdit v4.0. To be fair, Philips has worked on optimizing other operations such as saving and emulating, which took nearly as long as opening with the first release of PENG, but have since been slashed to mere seconds.
| 
Previous page
