Jump to content

Change the FP grid spacing programmatically?


JDave

Recommended Posts

As I was coding today, it struck me that there should be an easier way to wire controls up to the connector pane. I remembered seeing something along those lines here on LAVA. Apparently the search is working better, because eventually I found mballa's SubVI Fixer Tool. My thought before I found this tool was to have a LARGE grid spacing (~200). Then one can easily place the controls and indicators into these 'bins'. It is simple to then assign the controls to connector pane terminals. The rest of the code is found in the Fixer tool.

But as I searched through the property nodes and invoke nodes, I didn't see anything regarding the grid spacing. Does anyone know if there is a way to programmatically change the grid spacing? I thought about temporarily setting it to 200, then restoring the original settings.

Thanks for any thoughts.

David

Link to comment

I am also VERY interested in finding out if this is possible. I looked for such settings a while back but I could not find anything. Since I have to change this settings manually constantly for every VI I worked on that I did not create, having a way to do this programmatically would be very handy.

Below is what I want to be able to do programmatically:

From:

post-121-1191017740.png?width=400

To:

post-121-1191017757.png?width=400

Basically I hate to have to do this operation several times a day...

PJM

Link to comment

QUOTE(Michael_Aivaliotis @ Sep 28 2007, 03:39 PM)

I agree, this is very retarted. Why does every freakin' VI have to have it's own grid setting and why can't we globaly overide this? This is a dev. environment setting not a VI setting.

It is both a VI setting and an environment setting. The environment setting only works on newly created VIs. This wouldn't solve my problem, but it would be nice to have an additional dev. environment setting that specifies to ONLY use the environment spacing. This would only apply when opening VIs.

Link to comment

Developer A writes a VI with grid size 10. Developer B opens the VI on his machine to add a control to the FP. His default grid size is 13. If we used the environment setting for VIs when they were opened, instead of having each VI remember its alignement, then no matter which grid square Developer B uses, the new control does not drop aligned with respect to the other controls already on the FP.

The environment setting is the grid size for new VIs so that you can define the layout for each new VI. But after a VI is made, edits to that VI should stick with the layout chosen for that VI. Thus each VI remembers its own layout.

No, there is no programmatic interface (not even with some magic .ini token) for setting the alignment grid size on a VI.

Link to comment

QUOTE(PJM_labview @ Sep 29 2007, 01:36 PM)

In any case, in my opinion, the fact that develloper B wants to work with grid 13 outweight any other considerations.

Then change the layout of that VI to be a size 13 grid. But to open existing VIs with random (effectively) grid sizes such that the size used to achieve that layout is not preserved makes it impossible to make adjustments without blowing away the layout.

You mentioned the arrow keys and alignment tools. Those predate the alignment grid. They were ruled insufficient for laying out at VI. The alignment grid makes it possible to quickly do layout using certain rules (buttons should be XYZ size, controls should be N pixels apart, window border around controls should be Q pixels...) without having to count with arrow keys or copy a screenshot of the FP into a paint program to count pixels.

By your argument, the background color of the VI should change when loaded on a system where the programmer has changed the default background color instead of being saved with each individual VI. The grid size used to construct a front panel is integral to preserving the look/feel of a VI.

Link to comment

Here is my perspective/use case for this.

I have been using the grid for both BD and FP for years. None of my colleagues or customer ever use the grid, but LabVIEW is not aware of this fact, because by default there is always a grid setting selected (whether the grid is visible or not). When I opened a VI created with this invisible default grid, I have to change the grid to my defined preference every single time (and I have been doing it for years). If the VI is a User Interface I understand your argument of why it could be useful to preserve the FP grid, but honestly I do not do it. I have no problem not messing with the existing controls, and if I have to add some user element I have no problem using the arrow keys and alignment tool.

So what about adding a couple of ini settings to LabVIEW:

  1. If no grid settings are selected (either on the BD or FP) on a given VI, apply the user defined settings automatically.
  2. Always overwrite grid settings with user settings (which is basically what I have to do manually constantly) and let the user deal with the consequences.

PJM

Link to comment

QUOTE(PJM_labview @ Sep 30 2007, 10:43 AM)

  1. If no grid settings are selected (either on the BD or FP) on a given VI, apply the user defined settings automatically.

Just a quick note.

It turned out that LabVIEW does just that for file that were created prior to the existence of the grid (I just noticed this on a LV 4.0.2 file).

PJM

Link to comment

QUOTE(Aristos Queue @ Sep 30 2007, 10:36 AM)

Then change the layout of that VI to be a size 13 grid. But to open existing VIs with random (effectively) grid sizes such that the size used to achieve that layout is not preserved makes it impossible to make adjustments without blowing away the layout.

You mentioned the arrow keys and alignment tools. Those predate the alignment grid. They were ruled insufficient for laying out at VI. The alignment grid makes it possible to quickly do layout using certain rules (buttons should be XYZ size, controls should be N pixels apart, window border around controls should be Q pixels...) without having to count with arrow keys or copy a screenshot of the FP into a paint program to count pixels.

By your argument, the background color of the VI should change when loaded on a system where the programmer has changed the default background color instead of being saved with each individual VI. The grid size used to construct a front panel is integral to preserving the look/feel of a VI.

Hmm, I have to say that the FP grid does not work like this for me. I tend to drop controls on a front panel and then nudge them with the cursors to where I want them (or use alignment and distribution) since the grid simply does not work well for me independent of what settings I have it. I recently resorted to disable the grid snapping for most VIs I'm working on after I found this by accident.

For FPs that are meant to be visible to the end user the grid is to restrictive to get the look I want, since most of my FPs except the main screens usually really are application dialogs and use the system dialog style, and for other FPs I just put them so they are logically aligned in a similar manner than the connector pane is layed out.

As far as I'm concerned a global "don't snap to the grid" option would be the best I could ask for.

And yes my FPs usually adapt the background color to the system dialog background color too, so there goes your other argument :-)

Rolf Kalbermatter

Link to comment
  • 5 weeks later...
  • 16 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.