I am working on getting a VI to run as a stand alone application on a tablet computer. I have a few graphs and buttons and the like, and I want the whole finished package to look nice and fit well into the space on the tablet screen. I have a few questions about the best practice for doing this:
First, is there a good or proper way to design the front panel so that everything needed fits onto the tablet screen? If I know the resolution of the tablet, is there a good way to know how things will fit (without just using trial and error)?
Second, on the final project I don't want the user to be able to scroll away from the graphs, or access some of the options on the top bar of the front panel application window (for example, the edit tool bar, or the tools bar, etc.).
Finally, and a bit random, but when I open the application on a tablet computer it always opens on the far right of the screen, as though it expects there to be a second display in extend mode. Is there any way that is coming from the build specifications? It's not a huge issue but it doesn't look very professional.
Solved! Go to Solution.
Make sure that your front panel content is aligned with the crosshair.
Now go to vi properties ... Windows run-time position: pick size, position, monitor, select to scroll to origin, etc.
(I would avoid any settings that do scaling)
On a related note, now that I am near the end of this project I realize that I should have been organizing some of these front panel objects better. I only learned about how to make custom cluster type definitions during this project, but it seems like this should be used not just for organizing the block diagram but to group front panel objects together in logical ways. How do you more experienced users try to go about this when you start a new project? For example, I have a little box of controls that all contain data for the alarm system (max bounds, min bounds, alarm muted, alarm reset, etc. A handful of numeric inputs and some boolean inputs). Would this be the sort of thing you would make a custom control to organize, or does it make more sense to leave them as separate inputs on the front panel and just visually group them together as I did? If I did make this a custom control, could I still access the events for those objects from my main block diagram?
The main advantage of clusters in on the diagram where potentially dozens of terminals turn into one, greatly simplifying the code. Once the cluster elements are properly named, bundle/unbundle by name also makes the code very self-documenting.
Awesome, just what I was looking for! And yeah, since I've learned about clusters I honestly understand why people use LabVIEW a lot more. Up until now it's just been an inevitable mess of wires and shift registers, things are much better now and the unbundle by name thing basically documents for you.