Known Behavior or Bug?

[MangeshD]

Adding and reducing space in block diagram and front panel added a great advantage to increase or decrease space between controls indicators loops...etc.

But it doesn't work with activeX control/.net controls (may be it is  expected behavior, I really dont know..!)

I have added activeX container with object (example adobe acrobat reader) on front panel and try to increase/ decrease a space from that control in block diagram..it jumps on front panel. Same is not the case in front panel but on front panel it appears as blinking at old position while moving..

Not in LabVIEW 2015 and 2015 SP1 Known Issues

https://www.ni.com/en/support/documentation/bugs/15/labview-2015-and-2015-sp1-known-issues.html

Not yet reported !

Check the attached code or you can recreate it with a basic activeX control.!

[Sam_Sharp]

Are you talking about trying to increase the size of a .NET/ActiveX control/container by ctrl+dragging? I thought the ctrl+drag only works on empty space?

If you're having problems with ActiveX/.NET controls specifically - I don't think this is a 'bug' as such - more of an edge case that was never implemented/accounted for. Each ActiveX and .NET control actually sits in their own window which sits in front of the LabVIEW front panel (this is why you cannot have any controls indicators layered on top of .NET controls) so any clicks on/within the control will be handled by the control, rather than by the LabVIEW IDE.

[MangeshD]

Sam,

---

@Sam_Sharp wrote:

Are you talking about trying to increase the size of a .NET/ActiveX control/container by ctrl+dragging? I thought the ctrl+drag only works on empty space?

---

Not at all.! I was talking about the space between controls/labview functions/nodes etc.

 

If you're having problems with ActiveX/.NET controls specifically - I don't think this is a 'bug' as such - more of an edge case that was never implemented/accounted for. Each ActiveX and .NET control actually sits in their own window which sits in front of the LabVIEW front panel (this is why you cannot have any controls indicators layered on top of .NET controls) so any clicks on/within the control will be handled by the control, rather than by the LabVIEW IDE.

---

I am agree with you Sam but if the terminal of the ActiveX control (Which is similar to other terminals and can be moved to any position without affecting control which sits in front panel behaves wierdly)

We could say its an 'Edge case' but you must look at the code attached if you are not getting me (Specially Block Diagram.!)

[Sam_Sharp]

I don't have LV2015, otherwise I would have taken a look at your VI.

In any case, when I put a .NET/ActiveX control on the front panel, I can move it around using ctrl+drag in the space around it.

[Bob_Schor]

You might be nuts, but I see the same weird behavior that you do.  When I try to add or remove space by Ctrl-<drag> or Ctrl-Alt-<drag> anywhere on your Block Diagram, the cursor jumps to the Front Panel.  Deleting both the .net Button and AcroPDF returned the Add/Remove Space functionality, and adding the deleted controls back removed it again.

I guess when NI added "hooks" into Microsoft internal data structures (.NET and ActiveX), it clashed with some (probably also Microsoft) features that they were using to allow us to manipulate Space (the Final Frontier) more easily.  Sigh.

I wonder what would happen on a Mac non-Windows-based computer ...

Bob Schor

[MangeshD]

Looks like nuts are everywhere..!

There is no problem in older versions of LabVIEW.

[MangeshD]

Update:

NI escalted this to NI Austin.

[johnsold]

Bob,

Everything behaves normally on my Mac, LV 2015. Of course the .NET controls do not exist.

Lynn