Tab Control won't move on Block Diagram with ActiveX Container inserted

[cbutcher]

I feel like this is probably a bug (although the most extreme part is probably not LV's fault...)

The inserted ActiveX control appears on the block diagram when I move the Tab Control terminal.

To reproduce:

• Create a new VI
• Add a Tab Control
• Add an ActiveX container to the Tab Control
• Insert an ActiveX control to the container (attached VI uses CWGraph Control)
• Switch to BD and drag the Tab Control terminal around - see that the ActiveX Control is overlayed with the FP representation of the ActiveX control. The FP also gains focus in some cases.

I attach a VI which demonstrates what I expect is the cause of the problem. In my actual case, the ActiveX control doesn't appear (so I didn't realise what might be the problem) but the Tab Control terminal still can't be moved - the problem became clear when I used NI ActiveX controls (which are presumably better behaved) to create a minimal example.

Edit: Note also that if you move the terminal for the ActiveX control, this behaviour is suppressed for the next movement of the Tab Control terminal, but reoccurs on the second movement.

[Bob_Schor]

So I opened your VI and can see (some of) the situation you describe, but it seems entirely harmless.

• When I open the VI, I see on the FP a CWGraph ActiveX control on Page 1.
• When I switch to the BD and move the Tab Control, it simply "moves", as expected.
• When I move it a second (or third) time, an image of the ActiveX Control (as seen on the FP) appears, but only while I am moving the Tab Control.  As soon as I release the Mouse Button, it vanishes.  I consider this a "curiosity".
• If I switch the Tab Control to Page 2 (which has no ActiveX control), I can move the Tab Control on the BD all I want and nothing appears.
• When I switch back to Page 1, the momentary (while moving) ActiveX Image shows up again.
• Another curious fact -- when I started this test, the ActiveX Image appeared just below and to the left of the ActiveX Terminal.  When I moved the Terminal, the position of the Image seemed to stay in its original spot.  However, after moving the ActiveX control, I again got the "One Free Move" of the Tab Control without the ActiveX Image appearing.

I agree that this is a very strange, and probably not planned/desired, "Feature".  I wonder if it is in the Beta -- I'll test and if so, I'll inform the Beta team.

Bob Schor

[cbutcher]

Glad to know it isn't just my installation/poor mouse skills...

In this case, it's curious but not particularly problematic. However, with the ActiveX control that I'm working with, the tab control can't be moved at all.

Now that I found moving the container terminal allows moving the tab control, I at least have a workaround though, so that's helpful.

I'll also take a look on the beta - I hadn't considered trying it there.

[RavensFan]

What happens if you try to programmatically change the position of the tab control?

[Bob_Schor]

---

@RavensFan wrote:

What happens if you try to programmatically change the position of the tab control?

---

At least when I tried it, I wasn't touching the Front Panel, I was moving the Control on the Block Diagram, like I was editing a VI and wanted to "straighten out the wires" by moving the Control to a new position.  So far, I've always done this "by hand" ...  I thought this was what the OP was describing ...

Bob Schor

[NateBraska · Accepted solution]

I was able to reproduce this, and I have filed CAR 634637 for this. The CAR uses CWDGraph3D Control and Microsoft Web Browser objects as examples.

As a workaround, I was able to also use the keyboard arrow keys to move it, but the easiest option is to switch to a tab without an affected ActiveX control on it.

Nathan

[RavensFan]

---

@Bob_Schor wrote:

---

@RavensFan wrote:

What happens if you try to programmatically change the position of the tab control?

---

At least when I tried it, I wasn't touching the Front Panel, I was moving the Control on the Block Diagram, like I was editing a VI and wanted to "straighten out the wires" by moving the Control to a new position.  So far, I've always done this "by hand" ...  I thought this was what the OP was describing ...

Bob Schor

---

I think you're right.  In among all the descriptions of front panel vs. block diagram, I was thinking the tab control itself was stuck.

Thought it would still be an interesting attempt to see if another VI using VI scripting could move the terminal on the problem VI.

[cbutcher]

@RavensFan wrote:

---

@Bob_Schor wrote:

---

@RavensFan wrote:

What happens if you try to programmatically change the position of the tab control?

---

At least when I tried it, I wasn't touching the Front Panel, I was moving the Control on the Block Diagram, like I was editing a VI and wanted to "straighten out the wires" by moving the Control to a new position.  So far, I've always done this "by hand" ...  I thought this was what the OP was describing ...

Bob Schor

---

I think you're right.  In among all the descriptions of front panel vs. block diagram, I was thinking the tab control itself was stuck.

---

Sorry - for clarity in case others read this later, yes - the problem relates to moving the tab control terminal on the block diagram.

Good to know also about the arrow keys being able to move the control. Now I have several workarounds available.

Regarding the programmatic changing of the tab control position (not terminal) that works fine - as does just dragging it around, or using arrows.

[cbutcher]

Any chance someone could try this with 'CWDataSocket Control' inserted?

LabVIEW tells me I only have an evaluation copy of this control (so it might not be the control but the fact I don't have the full version), but it displays the same behaviour that my problematic control displays - it refuses to move at all (making this more than just a curious display of the control on the block diagram).

The same workarounds hold true here though - changing the tab, or moving the container terminal on the block diagram first allow moving the tab control terminal.

Edit for clarity: the 'it' in my second paragraph, beginning 'LabVIEW tells me' is in fact the Tab Control Terminal, not the Container. The problem is the same as discussed in the rest of this thread. I mean to say, that when this specific ActiveX control is inserted in the container, the tab control behaves in the same way as when the ActiveX control I'm trying to work with is inserted in the container - i.e. it won't move at all.

[JÞB]

Additional observations:

Start with TC ActiveXProblem vi. duplicate the Graph control. Then Add a sub BD Around the terminal of the Tab container

• Both graphs display on BD while dragging the Tab Container Terminal's LABEL! Yes this is repeatably linked to moving the terminal label whether or not the label is visible. This includes motions caused by live drag
• Moving the LABEL only of either Graph Control Terminal shows that graph only
• Live drag that moves the graph terminal and label show that graph artifact only
• Moving either graph terminal (and its label) without live-drag (via select then drag) does not show the graph artifact.
• Really funky: Move either graph terminal and you get 1 "Free Move" where Neither graph shows on the BD.  
• BD Graph artifacts appear at the FP location that is at the FP XY coordinates on the BD and Make/unmake space on the BD does not move artifact location
• Moving the Tab Container Label (on the FP) causes the Graph controls to flicker
• AND Totally WOW! the graph control artifacts can appear over horizontal and vertical Scroll bars on either the FP or BD

Seen in 2016 f1 32bit Windows

Especially note: I could not duplicate locking the tab container terminal on the BD.  however, cbutcher did not specify if the f1 patch was installed