DRivel

QUOTE (victorpiper @ Mar 16 2007, 05:21 PM) Hi, (I know this is an old thread) Having spent many hours trying to make SendInput work, I'm happy to find the solution here - to set cbSize to 28, instead of 20, the actual size of the KEYBDINPUT INPUT structure. Like Victor, I also wondered why 28 instead of 20, and expect it's because the INPUT structure is a union of three structures, and the size of INPUT is being determined by the largest structure in the union, which is the MOUSEINPUT structure. Belated THANKS! to COSMIN and Victor

Hi Folks, Thanks for the challenge! (you've lured me away from the NI LV Forum) Any way, it seems obvious (now :headbang: ) that the VI is supposed to execute immediately, but as it's not explicitly stated anywhere, I thought I'd ask!(?) I'm about to trash a VI that was designed to return a completed "Final" string - wouldn't terminate until a mouse-up or mouse-leave (or caller "Stop"). But the requirement as to the empty-state of Final, while mouse is down, implies that our VI executes immediately, so it seems our VI shouldn't wait for mouse events... Thanks!

Hi Folks, First time posting here - hope this doesn't sound lame or off-topic. I've found the nastiest gotcha with dynamic calls is when using the call-by-reference-node and I forget to update the type-specifier-for-VI-refnum after a typedef changes - because both the caller and callee look fine. This particular error aside, a nice tool for debugging dynamic-call errors is to open the front panel of the [broken] callee (using Open VI reference and FP.Open). Once opened clicking on the broken-arrow can deliver nice error detail - even in a run-time environment!