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...