Moving/Resizing diagrams

[Black Pearl]

This is a bit of a tricky issue you normally won't notice. But when I create a node on a diagram (For Loop), it's not exactly at the position I want it but there is an offset by 1 pixel. Furthermore, during this process Position and Bounds of the diagram also change. This issue isn't really noticable in most cases, but it becomes pretty severe when creating Shift Registers (I get offsets >100 pixels). This only happens when I have a node above the loop.

Deeper investigation of this issue hints me, that this has to do with automatic resizing the diagram. Just creating the for loop gives me a diagram with the bounds of 16x16. When I place the node on the diagram (or the ShiftRegs), it needs to be resized. I guess in this process, I lose the desired integrity of my positions. I target of an exact pixel location, to make the subsequent wireing possible. I did try with 'Make Space', but that moves the 'i'-Term around with even worse effect on diagrams Pos and Bounds.

Felix

[vugie]

Just quick thought: before creating any nodes, put 2 small decorations (or anything else, but delete them later) in the corners of suspected bounding box of your code.

[Black Pearl]

Had another idea and it did show correct:

The original diagram is covering the area of the 'i'-Term. So I need to use the i-Term as the reference postion. Still don't know exactly how to do this, but at least I've a new point to continue experimenting.

Felix

[Black Pearl]

Hmm, seems to be on the BD level already:

Create For loop, Create ShftReg, Create Const on BD -> fine (on first look)

Create Const on BD, Create For Loop, Create ShftReg -> ShftReg is Offsetted.

I'll need to look at the numbers to get more details.

Felix

[Black Pearl]

Forget about the ShiftRegister, I found a bug in my code. I was using the BD instead of the Loop for calculating the offset.

Still Everything I drop inside a for loop is moved by one to the bottom and to the right. Using nested for loops, it only happens once (the inner loop is moved, but not the contents in respect to it).

Felix

[Black Pearl]

I could replicate the behavior I saw with a unit cast. VI is attached.

Initial Position of the BD is Left=0. After I create the 'Convert Unit', the Pos is Left=6. Observations made in 7.1.

Felix

BD_Moved.vi