Leaderboard

FYI to anyone else who digs up this thread: Bean's VIs don't work if you have "Show revision number in titlebar" enabled in your LV Options and you execute the code in the dev environment. This is because it uses "FP.Title" as the window title.

I came here three years later following a post in the NI LabVIEW forums. I also had developed a set of ActiveX routines to "do things" in Excel, but found it tedious to get the documentation for the ActiveX functions, particularly with Windows 7 and LabVIEW 2012 (looks like Microsoft is moving away from ActiveX, anyway). I "bit the bullet" and tried using the newer LabVIEW Report Objects, and life got much easier. [Oops, can't figure out how to paste snippet in here, so I'll try to Attach my VI]. Hope this is helpful. BS EXCEL Delete WorkSheet.vi UTIL Ask Sheet Exists.vi

IAsyncResult is an interface, not a concrete class, so there is no constructor for it. You need a class that implements that interface.

Well the name of the Windows DLLs has not changed between 32bit and 64bit Windows just because they wanted to avoid to having to change all DLL names everywhere when referencing DLLs dynamically by name. The 32 in the name is a left over artefact since all these DLLs also had the same name without 32 in Windows 3.x. Back then when moving to 32 bit architecture the MS developers chose to use a distinctive name to avoid name collisions. When moving to 64bit, MS decided to use different base directories instead and leave the DLL names alone. So VIs accessing system DLLs can work both on 32bit and 64bit Windows but you need to be aware that some parameters can actually change in size. For instance any HANDLE datatype (almost every WinAPI datatype starting with a H) is a 32 bit entity in 32 bit Windows and a 64 bit entitiy in 64 bit Windows. So the right data type to use for such parameters is the (unsigned) pointer sized integer. If you use a normal 32 bit integer it may still work on resource constrained systems but will sooner or later fail badly when your system has more memory and the value of handles can go above 4GB address range. Same for any pointer that you decide to treat as integer type for whatever reasons and there are also a few other Windows datatypes that can change bitness.

Hi, i have question about array of clusters. I want to do some list of commands where i use table of arrays. In array are 2 tables one string and one image controller. I found code that find me active (clicked cell in this array but is there any way how to highlight this cell? I tried to changed background color of this cluster but this change color for whole table. Can you help me. My program is attached. editor.vi ClickedArrElement.vi

I suppose I'll clarify my point for just a sec, then I'll try to follow my own points (about to be given) and provide alternatives. I think using (not even abusing) the Val(signaling) property is far far worse than globals depending on usage. Hence the fervor. I don't expect pretty code out of the gate but I don't know how to stop a newbie from adopting poor practices out of the gate other than striking the fear of god into them. Agreed, using dynamic events 'as truly dynamic events' is not a beginner topic, but I believe the use of 'user events' are beginner material which only requires knowledge of the mechanics of wiring them up. and summing up those last few points: I think that a smarter person than I would not need the 'fear-o-god' tactic to discourage poor techniques. Rather it would be much more classy and eloquent to give knowledge to them through some simple example programs demonstrating the bad aspects and demonstrations of better ways to do it. Now onto my attempt at eloquence: Jim Carmody did a great job with exactly what I think San was gunning for so I'll try not to replicate that First on some of the dangers of using the Val(signaling) Some simple programs are created that are fully reactive (waiting for some event to happen) and you will see this as just an event structure in a while loop. <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8689b74b-ac72-44c8-952e-80c386e03c21/2009-11-29_1536.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/8689b74b-ac72-44c8-952e-80c386e03c21/2009-11-29_1536.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8689b74b-ac72-44c8-952e-80c386e03c21/2009-11-29_1536.png" width="448" height="226" border="0" /></a> And depending on the scope of the code, this can get the job done just fine and avoid extra coding that may never be utilized. But the problem, and this sounds much closer to what San was looking at, is what happens when you now need to invoke the code within this state without the user hitting a button? By default, if the user doesn't know any better, they'll use the Val(Signaling) property. This is typically because it will require almost no extra code to be written other than dropping that property node. Well this starts to snowball into a bigger issue when someone decides that they just don't want to execute that one event state, but rather I need 4 states executed and I want that state to always be the second of the 4. What typically happens, is that the end user just starts stringing together multiple Val(signaling) properties for multiple controls to call multiple event states. This is particularly bad because there is no guarantee that as you string together Val(signaling) properties that they'll execute in that order, so you've just introduced potential bad logic in your vi. Now it gets even trickier if you like to use property nodes all over you code because if you need to better understand the flow of the program, how do you know who and what is controlling the state firing? Search for Val(signaling): you get all usages of that property (fail). Search for all property nodes of a given control: you now find every property of a control and you only find the property nodes that are directly linked to that control and you miss any non-linked property node. <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/54b79210-0b47-42d6-9770-4be1f36bbe13/2009-11-29_1555.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/54b79210-0b47-42d6-9770-4be1f36bbe13/2009-11-29_1555.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/54b79210-0b47-42d6-9770-4be1f36bbe13/2009-11-29_1555.png" width="437" height="142" border="0" /></a> And just to re-itterate. Don't underestimate the need to understand the flow of a program. You will someday need to re-learn what you wrote. Someone's LAVA tagline is perfect for this "Imagine the next person to work with your code is a deranged psychopath and knows where you live" So now onto some alternatives and notes about the Val(Signaling) property. Its intent in life is to provide that 'if all else wont work' kind of functionality to the LV language. An example of this is when using the data terminal of an event case. In this case you want that data on the terminal and the only way to programatically fire that event and still have that data is through the Val(signaling) property <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/41648ccd-13e7-4e07-9cce-b867b4dc6821/2009-11-29_1605.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/41648ccd-13e7-4e07-9cce-b867b4dc6821/2009-11-29_1605.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/41648ccd-13e7-4e07-9cce-b867b4dc6821/2009-11-29_1605.png" width="448" height="223" border="0" /></a> Now the alternative or smarter architecture associated with this, is to have the event cause a reaction in some other piece of code somewhere else that you have more control over than an event structure. This is where a solid event driven producer consumer design pattern comes in handy. I won't go into the architecture of this here but what this does allow you to do is have the code to be executed in a place that can be easily invoked programatically or interactively. Do the amount of wires increase? yes. Does the architecture increase in complexity? yes. Do you have a much more flexible and debuggable piece of code for just a little more effort? No question about it absolutely. So for the how-to-do-it portion of the code. San, It sounds like you are monitoring your code for the 0xFF Byte and want some other part of code to react when this happens. The code that Jim sent is about spot on and the only other thing that you'll need to do is share the reference to that newly created user event around your codebase. <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/6f18fd2d-c4a3-4e6b-9c38-c62bac86edf8/2009-11-29_1617.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/6f18fd2d-c4a3-4e6b-9c38-c62bac86edf8/2009-11-29_1617.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/6f18fd2d-c4a3-4e6b-9c38-c62bac86edf8/2009-11-29_1617.png" width="316" height="265" border="0" /></a> The part of code that needs to fire the event, will use the 'Generate User Event' vi <a href="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8a8cf0e9-cc0d-445d-acf9-b9483e37fbcf/2009-11-29_1619.png"><img'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/8a8cf0e9-cc0d-445d-acf9-b9483e37fbcf/2009-11-29_1619.png"><img class="embeddedObject" src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/8a8cf0e9-cc0d-445d-acf9-b9483e37fbcf/2009-11-29_1619.png" width="235" height="488" border="0" /></a> And all parts of the code that need to respond to that event need to dynamically register for that event and then have an event case that registers for it. <object width="810" height="612"> <param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/jingh264player.swf"></param>'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/jingh264player.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/FirstFrame.jpg&containerwidth=810&containerheight=612&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/2009-11-29_1624.mp4"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/"></param>'>http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/"></param> <embed src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/jingh264player.swf" quality="high" bgcolor="#FFFFFF" width="810" height="612" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/FirstFrame.jpg&containerwidth=810&containerheight=612&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/2009-11-29_1624.mp4" allowFullScreen="true" base="http://content.screencast.com/users/NJKirchner/folders/Jing/media/e17f4a92-a2a5-428a-b981-2393f28ebc2a/" scale="showall"></embed> </object>

Bad bad bad jgcode. Bad! San... Please disregard the any mention of the (signaling) property. This is something that is VASTLY abused and should be avoided at all costs. let me repeat, DON"T USE THE SIGNALING PROPERTY unless no other way of doing it. Newbies use this methodology in excess and end up really regretting it down the line. This tactic is not easily traceable, debuggable or extendable (going N+1) Just look at some of the stock examples that come with LabVIEW for user events and dynamic events. Your effort will pay off 20 times easily in better code. Long story short, if you want reactive code to a user input, utilize an event structure to respond to that action. If you want reactive code to a group or types of controls/indicators look into dynamic event registration If you want code to react to programatically to different parts of programs (without user input) then look into user events. and once again BAD JGCODE!