Jump to content

hWnd for cw3DPlot in LabVIEW


Recommended Posts

Posted

Hello:

Component Works control, namely the 3-D plot control, is infact an ActiveX control. Yet, its LabVIEW property node does not expose an hWnd property. Does anyone know why? I need this to use a third party reporting tool to render the image of the object on a report page.

. . . I know that this can be done using LabVIEW's getImage method but I want to use the hWnd approach because it gives cleaner report print-outs.

Thanks

Anthony

Posted

There is a VI in Vision toolkit that gets the hWnd located in "..\vi.lib\Vision\Extlibsp.llb\IMAQ Get Window Handle.vi"

However, I'm not sure it's possible to get the hWnd this way because it needs a "window number" which I think has to be a window previously opened by LabVIEW Vision. You might need to use Windows APIs for that.

Posted

QUOTE (neB @ Jun 2 2008, 02:54 PM)

What is the Window Title for the 3d-graph container for use with that function? I can't even venture a guess.

Ohhh - that's a really good point - I hadn't thought of that. Is there anyone from NI here with the inside knowledge to this? Does it even have a window title?

Posted

When I have a need to find information about a window I us a tool that ships with AutoIt (AutoIt Window Info). Consequently I made a blank VI with a 3D graph control in it and the 3D control does show up in that tool as a control, but without a seperate "window handle". It might be worth downloading AutoIt to see if it would help get you the information it needs to access the window handle for that control.

Posted

<p style="text-align: left;"><a class="noborder" href="http://lavag.org/old_files/monthly_06_2008/post-10515-1212439546.jpg" target="_blank">post-10515-1212439546.jpg?width=400</a></p>

Building on crelf's input, I used the GetTopWindow() to get the child window's handle (CW Graph) of the current VI, without need of CW graph window title.

Download File:post-10515-1212439407.vi

(LabVIEW 8.5)

Posted

QUOTE (normandinf @ Jun 2 2008, 03:46 PM)

...I used the GetTopWindow() to get the child window's handle (CW Graph) of the current VI, without need of CW graph window title.

Nice! :thumbup:

Posted

QUOTE (normandinf @ Jun 2 2008, 04:46 PM)

post-10515-1212439546.jpg?width=400

Building on crelf's input, I used the GetTopWindow() to get the child window's handle (CW Graph) of the current VI, without need of CW graph window title.

Download File:post-10515-1212439407.vi

(LabVIEW 8.5)

Works nice! But only as long as there is one single ActiveX/.Net control on the panel.

Rolf Kalbermatter

Posted

QUOTE (crelf @ Jun 2 2008, 03:59 PM)

Ohhh - that's a really good point - I hadn't thought of that. Is there anyone from NI here with the inside knowledge to this? Does it even have a window title?

Nope that window does not have any title.

Rolf Kalbermatter

Posted

Hello:

Thanks for the activity on this question.

My VI has one Active X control window so I may be able to use this technique. I need to test to see if the handle will render the 3-D control on the document. Will soon provide feed-back.

Anthony

  • 12 years later...
Posted
On 6/4/2008 at 1:52 PM, Rolf Kalbermatter said:

Works nice! But only as long as there is one single ActiveX/.Net control on the panel.

When I found a way to obtain the object's pointer given its refnum, I remembered my old and currently declined idea on NI Forums - Ability To Get .NET/ActiveX Window Handle By Its Automation Refnum. The solution proposed there is not good for many reasons, so I decided to see, whether I could pull out a HWND of NI Container Clipping Window from LabVIEW's internals using the object's pointer only. After some experiments I have succeded! So, now it's clear that LabVIEW retains that HWND in the memory to be able to do some manipulations with the window (like resizing / moving etc.).

Okay, here's my VI for getting a HWND from ActiveX or .NET Refnum. It requires Find BCJ for ObjRef.vi and Extract ObjRef Pointer.vi from this thread.

ActiveX_NET_Refnum_to_HWND.rar

2020-10-31_16-23-45.jpg.b3a9e6987e356cd014a84d771d7daec0.jpg

2020-10-31_16-45-43.jpg.e9d36acd14d935f1be87f8169c439b45.jpg

Tested this on every LabVIEW version from 2009 to 2020 (both 32- and 64-bit and both IDE and RTE). There are some constant offsets hardcoded on the diagram, therefore it's not guaranteed to work in the upcoming LabVIEW releases. But on practice only the one offset could change and it's easy to find it out with Heap Peek.

To do this (if needed):

  • Place ActiveX or .NET object onto the panel and launch Heap Peek.
  • Choose FPHP and find ActiveX Container in the objects list on the right (use F button to see the object).
  • In the object's data space find streamData pointer (marked red on the picture below). You need the address right before this pointer (marked green).
  • The offset, you want, is written on the left of the dump (marked blue).
  • Just use this offset with your LV version and you're done.

2020-10-31_15-15-41.jpg.742d3b35c931b34a351f9668600bfb21.jpg

Posted (edited)

Well of course does LabVIEW have to retain the HWND of the container where it places the ActiveX Window. And this is simply a specfically allocated window handle for the container since an ActiveX control requires a parent window when being instantiated and LabVIEW for obvious reasons does not want to hand the full front panel HWND as that would give the ActiveX Control every possibility to mess with the LabVIEW owner drawn front panel (as you know LabVIEW controls, except the ActiveX and .Net Container are not implemented using window controls with their own HWND as with other standard Windows applications, but are fully owner drawn by LabVIEW itself).

I still think that the approach with peeking into the object pointer to retrieve information, while being fun to do if you love this low level stuff, is an absolute and big NO-NO for anything that is supposed to leave your mancave.

Edited by Rolf Kalbermatter

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.