ActiveX(Treeview) in LabVIEW

[intp56]

I've been looking through the forums and haven't seen my problem. I'm using the MSTreeView 6.0 (I've put two nodes in there). I can detect events (in this case, I'm most interested MouseMove) and I can display the X,Y values from elements 2 and 3 of the ParamData Array.

I have HotTracking turned on. After mousing around for a while, I've determined that Node 1 gets highlighted when 0 <= X <= 69 and 1 <= Y <= 13. Node 2 gets highlighted when 0 <= X <= 69 and 14 <= Y <= 27.

The problem comes when I feed those values into HitTest. It returns Node 1 when X any and 0<= Y <= 202. It returns Node 2 when X any and 203 <= Y <= 363 (The Max Y value). Is there some conversion needed? I don't understand why the values I get back from MouseMove wo
uld be different than the values I give to HitTest.

Thanks in advance.

Bob Martin

[intp56]

Some more information. I checked out the code for "Embedding ActiveX containers.." which dealt with LV5, and the TreeView control did not have a HotTracking property. Also, hunting around Microsoft's web site, I gleaned that MouseMove always returns coordinates according to "ScaleMode", which doesn't seem to be a property I have access to with TreeView 6.0. The default is TWIPS. The section for HitTest doesn't say what the coordinate units are for X & Y. However, it does mention that HitTest is usually used with OLEDragDrop operations, and those functions seem to use pixels for the coordinates. The largest values I get from MouseMove are 262,363 in the lower RHCorner. LabVIEW tells me the size of the control is 273,374. Offhand, I'd say the numbers I'm getting are pix
els. It seems like what I've done should work. Is there some "feature" I'm missing?

Bob Martin

[David Duffey]

Hi Bob,

Could you attach an example VI? I couldn't find the MoveMouse (except the LabVIEW Mouse Move event). I've used the Tree control before, so I should be able to help you.

Also, can you explain why you are interested in finding out what item is at a specific location? Maybe if I knew what you are trying to accomplish with your application, we can find another way to do it also.

Thanks!

[intp56]

Sure, I've made a VI that demonstrates the problem.

What I have is a user can load data files, each file has 0 or more sets of data in it. Usually, the user is interested in only a couple of the data sets. I'm trying to get a graph that has multiple plots in it.

My idea was to use the TreeView. Nodes that are checked are displayed in the graph. The Selected Node is also displayed, and the index of the ClusterArray that holds other data it set to display the data for the Selected Node. (In addition, as the user changes which set of data is being displayed, the Selected Node changes) The users wanted a quick way to see the other Spectra so they could decide which ones to include in the graph. I thought the "Quick Way" would be to use the MouseMove e
vent coupled with HitTest to temporarily add the Spectra associated with that Node to the graph. If it turns out I can't do what they want, then I'll force them to actually click on a Node to display it's spectra.

This is really a "Wouldn't it be nice if......" kind of thing.

Bob

[intp56]

Oops, I sent an older version of the software. Here is the version I actually sent to NI. They've replicated the problem, but haven't gotten back to me as to where the problem is. You need to have TreeView 6.0 installed.

[wiebe@CARYA]

Hi,

This behaviour is normal. I tried it, and got the same thing. I also tried
some windows coordinate transformations (MapWindow..., GetWindowOrg, and
some others), with Hwnd combinations of the AX control, the desktop and the
VI. They all add an offset, but do not scale the coordinates.

Also, I viewed some examples. The examples don't seem to do anything
special. They just read the event, and feed the coordinates directly into
the HitTest.

Fortunatelly, I don't need it (I use the Selected Item property). Is there
any reason you can't use this property?

Regards,

Wiebe.


"INTP56" wrote in message
news:506500000008000000767C0000-1042324653000@exchange.ni.com...
> I've been looking through the forums and haven't seen my problem. I'm
> using the
MSTreeView 6.0 (I've put two nodes in there). I can detect
> events (in this case, I'm most interested MouseMove) and I can display
> the X,Y values from elements 2 and 3 of the ParamData Array.
>
> I have HotTracking turned on. After mousing around for a while, I've
> determined that Node 1 gets highlighted when 0 <= X <= 69 and 1 <= Y
> <= 13. Node 2 gets highlighted when 0 <= X <= 69 and 14 <= Y <= 27.
>
> The problem comes when I feed those values into HitTest. It returns
> Node 1 when X any and 0<= Y <= 202. It returns Node 2 when X any and
> 203 <= Y <= 363 (The Max Y value). Is there some conversion needed? I
> don't understand why the values I get back from MouseMove would be
> different than the values I give to HitTest.
>
> Thanks in advance.
>
> Bob Martin

[intp56]

Here are some things I've uncovered.

I've determined that the same behavior is seen using the TreeView with Excel VBA. However, using the TreeView with VB6 works (on the same machine). Apparently, when using VB6, the TreeView.MouseMove event returns the X,Y coordinates in TWIPS. In Excel VBA and LabVIEW, TreeView.MouseMove returns the X,Y coordinates in Pixels. In either case, TreeView.HitTest expects the X,Y coordinates in TWIPS.

I don't know how .NET affects all this. As I understand it, there is no simple TWIPS = Pixels * n conversion. There is a TWIPStoPixelsX (and Y) function, but Excel VBA doesn't know about it, so I doubt LabVIEW will. Someone suggested that I hit the Win32API to get pixels per inch information (since 1440 TWIPS = 1 inch), but di
dn't give me more information than that. I've cruised the MSDN website, but couldn't find any such call.

As I see it, the behavior of the TreeView control itself is not consistant from VBA to VB6, so I don't think NI will be able to do anything about it. I'm sure Microsoft's position will be, "It works if you use our development systems, so what is there to fix?". I think I will just have to give up on this idea.

Unless some can come up with an easy way to do the translation, I'll simply force my users to actually click on a node to generate the required event.

Bob

[intp56]

Weibe,

Thanks for your input. See my latest comment above. This feature was not a show stopper, but rather a "I thought it would be cool if..." kind of thing. At any rate, I know where the "problem" is, so I won't be spinning my wheels trying "one more thing".

Bob

[wiebe@CARYA]

Hi,

How about the function:

int SetMapMode(
HDC hdc, // handle to device context
int fnMapMode // new mapping mode
);

And GetMapMode?

Some modes are: MM_ISOTROPIC, MM_TWIPS,
MM_TEXT,MM_LOMETRIC,MM_LOENGLISH,MM_ANISOTROPIC

Don't know if you should use the VI's Hwnd or the Container's to get the DC.

I'll try it myself, it sould be easy...


Regards,

Wiebe.

"INTP56" wrote in message
news:506500000005000000D3DC0000-1042324653000@exchange.ni.com...
> Here are some things I've uncovered.
>
> I've determined that the same behavior is seen using the TreeView with
> Excel VBA. However, using the TreeView with VB6 works (on the same
> machine). Apparently, when using VB6, the TreeView.MouseMove event
> returns the X,Y c
oordinates in TWIPS. In Excel VBA and LabVIEW,
> TreeView.MouseMove returns the X,Y coordinates in Pixels. In either
> case, TreeView.HitTest expects the X,Y coordinates in TWIPS.
>
> I don't know how .NET affects all this. As I understand it, there is
> no simple TWIPS = Pixels * n conversion. There is a TWIPStoPixelsX
> (and Y) function, but Excel VBA doesn't know about it, so I doubt
> LabVIEW will. Someone suggested that I hit the Win32API to get pixels
> per inch information (since 1440 TWIPS = 1 inch), but didn't give me
> more information than that. I've cruised the MSDN website, but
> couldn't find any such call.
>
> As I see it, the behavior of the TreeView control itself is not
> consistant from VBA to VB6, so I don't think NI will be able to do
> anything about it. I'm sure Microsoft's position will be, "It works if
> you use our development systems, so what is there to fix?". I think I
> will just have to give up on this idea.
>
> Unless some can come up with an easy way to
do the translation, I'll
> simply force my users to actually click on a node to generate the
> required event.
>
> Bob

[wiebe@CARYA]

Hi,

Skip all the previous, it doesn't work anyway...

The factor for me is 15. So the MouseMove parameters must be multiplied by
15.

Why 15?

My number of dpi (dots per inch) is 96. The TWIPS means a factor 20 of
printer dots, which is always 1/1440. So, 1440 / 96 = 15!

So the new question is, how to get the dpi...

Regards,

Wiebe.



"Wiebe@AIR" wrote in message
news:3e7987b9$0$150$e4fe514c@dreader9.news.xs4all.nl...
> Hi,
>
> How about the function:
>
> int SetMapMode(
> HDC hdc, // handle to device context
> int fnMapMode // new mapping mode
> );
>
> And GetMapMode?
>
> Some modes are: MM_ISOTROPIC, MM_TWIPS,
> MM_TEXT,MM_LOMETRIC,MM_LOENGLISH,MM_ANISOTROPIC
>
> Don't know if you should use the VI's Hwnd or the Container's to get the
DC.
>
> I'll try it myself, it sould be easy...
>
>
> Regards,
>
> Wiebe.
>
> "INTP56" wrote in message
> news:506500000005000000D3DC0000-1042324653000@exchange.ni.com...
> > Here are some things I've uncovered.
> >
> > I've determined that the same behavior is seen using the TreeView with
> > Excel VBA. However, using the TreeView with VB6 works (on the same
> > machine). Apparently, when using VB6, the TreeView.MouseMove event
> > returns the X,Y coordinates in TWIPS. In Excel VBA and LabVIEW,
> > TreeView.MouseMove returns the X,Y coordinates in Pixels. In either
> > case, TreeView.HitTest expects the X,Y coordinates in TWIPS.
> >
> > I don't know how .NET affects all this. As I understand it, there is
> > no simple TWIPS = Pixels * n conversion. There is a TWIPStoPixelsX
> > (and Y) function, but Excel VBA doesn't know about it, so I doubt
> > LabVIEW will. Someone suggested that I hit the Win32API to get pixels
> > per inch information (since 1440 TWIPS = 1 inch), but didn't give me
> > more information than that. I've cruised the MSDN website, but
> > couldn't find any such call.
> >
> > As I see it, the behavior of the TreeView control itself is not
> > consistant from VBA to VB6, so I don't think NI will be able to do
> > anything about it. I'm sure Microsoft's position will be, "It works if
> > you use our development systems, so what is there to fix?". I think I
> > will just have to give up on this idea.
> >
> > Unless some can come up with an easy way to do the translation, I'll
> > simply force my users to actually click on a node to generate the
> > required event.
> >
> > Bob
>
>