Change the FP grid spacing programmatically?

[JDave]

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

[PJM_labview]

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:

To:

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

PJM

[Michael Aivaliotis]

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.

[JDave]

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.

[Michael Aivaliotis]

QUOTE(dsaunders @ Sep 28 2007, 04:52 PM)

...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.

I agree. :thumbup:

[Aristos Queue]

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.

[PJM_labview]

QUOTE(Aristos Queue @ Sep 28 2007, 10:37 PM)

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.

I have to say that the reasoning behind this does not convince me. So develloper B grid is 13, and he can't snap his new control to be aligned with the existing one, and??? He can still align it manually (

) or use

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

PJM

[Grampa_of_Oliva_n_Eden]

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

...develloper B wants to work with grid 13 outweight any other considerations.

PJM

Prime number gird spacing...

Imagine if every developer in a LV shop used different prime numbered grid spacing. :headbang:

Ben

[Aristos Queue]

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.

[PJM_labview]

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

[PJM_labview]

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

[Rolf Kalbermatter]

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

[Michael Aivaliotis]

Here's a nice trick for those that don't use (or ever will use) the grid. Every time you work on a VI, change the grid settings in the VI properties to some crazy out of this world value. Then sit back and listen to the screams comming from the neighboring cubicals...

[Aristos Queue]

QUOTE(rolfk @ Oct 2 2007, 01:29 AM)

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

You have this. You can set it in "Tools>>Options", but it is also available at "Edit>>Disable panel grid alignment". It even has a shortcut key.

[Norm Kirchner]

How about having the FP size and scroll snap to grid positions?

Just something that I hate to have to do to get 0,0 at 0,0 and get the screen size dead nuts on a line.

y'all w/ me on this one?

[eberaud]

Only 17 years later 😅 ... Has the situation changed? Or is it still impossible to change the grid size programatically? 

Thanks!

[dadreamer]

1 hour ago, eberaud said:

Only 17 years later 😅 ... Has the situation changed?

Is this what you are looking for?

Front Panel Window:Alignment Grid Size

VI class/Front Panel Window.Alignment Grid Size property

LabVIEW Idea Exchange: Programmatic Control of Grid Alignment Properties (Available in LabVIEW 2019 and later)

[eberaud]

Yes! Thank you 🤩