peterp

Hi JKSH et all thanks for the code snippet, now I got it (and find my error in my code) - I forgot to really save the changes I already made :-( Shame on me! Peter

Hi, thanx for all your suggestions, I will check them. BTW, I already knew of "LabVIEW Icon API" and used it to create new VI's with proper icons, but I was not able to edit existing ones, so that the existing layer structure is preserved. I only want to add a top-most layer, to keep the old ones still available as backup... But I will check again, also the OpenGDS. To clarify my approach, I've added a sample vi (LV2017). I want to open an existing VI, add a user layer and text, and save them a copy of the VI. Peter _Test_VI_Icon.vi

Hi, We're about to re-structure our VI source tree and therefore I'm looking for a way to automatically edit/change the VI icons as well. To do so, I want to open all VI's and change the icon text as well as add a new icon layer (on top) and then save this VI (perhaps also rename it, move it to another location ...) The only problem I have - I can (with help of Icon editor API) open the existing VI, get the icon data (separate entries for text, different layers, ...) and adjust them to new informations/texts/icon layers. But it is not possible to write back these changes to existing VI, I can only create a new VI with this data. Or I can overwrite any old icon settings by passing a new icon, loosing all different icon layers and separate texts. Is there any way to edit an existing VI Icon without loosing the existing icon texts/layers? I even tried to open the original icon editor via script and do the edits with "SendInput" remote control of it's user interface. But didn't find a way to open the icon editor on first hand :-( So any ideas highly appreciated! Peter

I now found the problem with the window handling/handle in LabVIEW 2012, 32bit. Hopefully can solve this soon... BTW: Any idea, why "GetWindow" (of user32.dll) falied with error 1517," LabVIEW: (Hex 0x5ED) An error occurred in the Call Library Node processing." when calling with parameter hWnd, GetNExtHandle (2) ? ...

You're right, I guess I should "finalize" Version 1.0 of "TaskDialogIndirect". Just for curiosity I had to implement "NamedPipes" function for an LabVIEW application; this is where I got stucked... And, as I mentioned, I do not like a solution depending on another dll, should work "out-of-the-box".

Wow, quite some traffic in this thread ... As I mentioned, I can now use API-Calls to find "my" parent window. Just curios, which call will be, Dll-Calls to get Process list and than look for the window handle of the LabVIEW application or use the "Get HWND and PID" and obtain there the "MaiWindowHandle". BTW, I also added a progress bar example of the TaskDialogIndirect. I also tried to implement a few "NamedPIpe" functions. Perhaps you guys can have a look? Especially the Named Pipes (I only found some old code, using a wrapper dll, which I did not want) will not work ... Even I thought I just translated the examples of msdn (https://msdn.microsoft.com/de-de/library/windows/desktop/aa365588%28v=vs.85%29.aspx https://msdn.microsoft.com/de-de/library/windows/desktop/aa365592%28v=vs.85%29.aspx) to LabVIEW code... WinAPI.zip

I've re-structured (again) the library, because it uses now quite some api-calls of windows. What do you think? I'm now able to make the dialog modal as well, even when I don't understand, why the "Parent Window" of an LabVIEW executeable is not named like executable... There is still something to do, because the window routines are currently x64 only... WinAPI.zip

Oh, just saw your answer after editing my last post ... I use now GetTopWindow and GetNextWindow, and will search in ProcessList for the correct executableFile, obtain it's ProcessID and will check the open windows for this ProcessID. (see attachments in my previous post)

I found this http://forums.codeguru.com/showthread.php?353149-How-to-Get-windows-Handle-using-Process-Id maybe it will work; I'm just implemementin git in LabVIEW... OK, I got this code running (GetProcessIDsOfWindows)... I also got the GetWindowHandleOfExecutable running, so I can get in the list of processes my application and will look with this ProcessID for the approbiate window handle... works nice. Just one question, before I will post all code: Is there a way to use "memset" in conjunction with DSNewPtr and MoveBlock, the LabVIEW build-in memory handling routines? I want to avoid re-creating memory pointer and free them each iteration to get an initialized memory block ... GetProcessIDsOfWindows.zip

According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms682489%28v=vs.85%29.aspx I can just use plain Dll-Calls (I'm not using "EnumWindows"...) Oh, just saw, there is some "EnumWindows" ... Will try to find another solution ...

Regarding the window handle, I found some note here: http://www.delphi-treff.de/tipps-tricks/system/prozesse/fensterhandle-anhand-des-exe-namens-erhalten/ which basically uses the application executable name to get the approbiate window handle. Now I'm struggeling a little bit with this dll call und structure ...

I llike these improvements ... very nice! Now I found also the reason why the Dialog is not "modal"; you have to specify the main application window handle; currently I just use the window handle of the internal core vi. Are there any ways to get this information without using a global, another input to the core vi? Because I can't use a fix name to get the window handle. And when I ask the application property "App.AllVIs" in memory and filter for execution state "Run top level", it's really slow. BTW: I could open your edit version w/o any problem in LV2012...

OK, I've found some u32-errors in the 32bit code; now the footer and detailed text is working like it should be ... Next steps will be to create nice and easy-to-use VI's to create the approbiate dialogs without to configure all stuff and flags ... TaskDialogIndirect Source.zip

Ok, I found some minor issues preventing the custom titlebar within 32bit LabVIEW; there seems also some issues with the "built-in" icons and the footer. I already correct the window title and built-in icons, now struggeling with the footer. Regarding your side note: The sample was just quick'n'dirty, therefore I made it "the old way" BTW, I've also attached a sample, how the "footer" option will look like (sample is with the wrapper, used within 64bit LabVIEW) TaskDialogIndirect Source.zip

Hi, ok, how do I move the thread to CR? For licensing, I guess it will be BSD (or MIT/X-Windows-License); so feel free to edit (or correct) the code, use it in commercial or free applications, just keep the original mark in the VI's blockdiagram...

I've re-designed the code a litle bit, now some parts are also working with LabVIEW 32bit and 64 bit as well (except the icon handling, there I have to digg a little bit ...) TaskDialogIndirect Source.zip

Ok, here's the first rough version of the dll-calling VI as well as some SubVI's and controls.The code is currently 64bit only, and created by LabVIEW 2012. I will add 32bit support in next future... Things to do/add: - add conditional case to determine byteness, therefore create 32bit dll wrapper - maybe also add case to detect OS prior MS Viste (no TaskDialogIndirect function available) - create some "easy-to-use" sub-vi's for the most important functions - create some nice icons for the vi's - ... TaskDialogIndirect Source.zip

Hi, I know this dialog "MessageBox" from windows, I now uses (after fighting with the dll call ...) the TaskDialogIndirect. This is a much more flexible function, allowing you to configure the button names, use custom icons and more. For more details see http://weblogs.asp.net/kennykerr/Windows-Vista-for-Developers-_1320_-Part-2-_1320_-Task-Dialogs-in-Depth WHen I finished the code (perhaps some bundling in a library), I can post my code here

I used on first hand the correct sized LabvIEW data types in the cluster, but I got some messed up data when I debug the data in a c-dll-wrapper. This is why I thought there is some data type miss-matching within LabVIEW. Now, when I use a plain byte-array to transfer the data, it works just fine . All the other structure elements were quite easy, once I figured out, how I have to swap u64 (64bit handles) to be used in a C-dll.

As I told you, I like such code-digging ... I saw in my wrapper dll the raw-data as transferred via the LabVIEW call. Seems like LabVIEW will special interpret the cluster data and I need to swap bytes, words and "64bit handles" in order to work. Now I have a working TaskDialogIndirect, need some more fine-tuning for buttons/labels/icons, but at least works.

There seem to be no "ready-to-use" .net library within Windows; sometimes mentioned a "WindowsAPICodePack", which is no longer available from Microsoft. I'm now just create the small wrapper dll ...

Hi, yes, It's correct, I have to create such a vi byteness-specific... And, yes, the structure is quite nasty. But I thought, because I can already open the dialog via function call, there is only small way to go to get the parameter correct. I hoped, I miss just one point in my implementation, which an expert can easy find out... Maybe there is a .net implementation (in the already included libraries of windows) to get this dialog? And, I like it to create an application that fits more nicely in the windows enviroment, regarding the message boxes... Peter PS: Honestly, sometimes I like such challenges...

Hi Rolf, I'm a little bit unhappy with the built-in-LabVIEW MessageBoxes, so I wanted to get the windows-built-in boxes to use. (They are much more conforming to styleguide ..., I also like their possibilities to be conform to the actual windows display scheme. Have a look at http://http://weblogs.asp.net/kennykerr/Windows-Vista-for-Developers-_1320_-Part-2-_1320_-Task-Dialogs-in-Depth) I'm able to use the "Messagebox" from user32.dll, but wanted the more flexibility in "TaskDialogIndirect", such as specifying an icon and own labeld buttons. As I already wrote, I can use (parts of) the structure to at least call the function (without a labVIEW crash), and see the "empty" dialog from this dll. Now I'm only looking for a small hint to get it's parameters to work. Of course, I can create my small wrapper, but would prefer a smaller solution, also to be able to distribute the application with less depencies. Peter

Hi, I'm try to get a hint to make correct usage of the TaskDialogIndirect of comCtl32.dll It's Header will be and the interesting part is the structure I can call the function, get with no additional settings an empty dialog. BUt I'm not able to set any parameter in the structure, seems like it's content is messed up ... I use LV2012, 64bit on Win7, 64bit. Thx for your help! Peter PS: I've also posted this question at ni.com, but have the impression, here are the smarter guys