Ton Plomp

I added the info to the LabVIEW Wiki page on XControls

I'm running WinXP Ton

I was able to create such a VI with the following settings: Here's the code I used for making it 10 pixels high: And heres the FP overlaying the code: And I would just ignore the error 1... (see attachment). (The reason your resize is ignored, is because the resizing outside the while loop generates an error, preventing the resize/move inside the event loop to happen.) Ton green line.vi

As soon as I read the initial post I was thinking about TotalCommander that has several quite popular patches (TC PowerPack is my favorite), that includes a lot of customization that allows you to integrate the most idiotic features (virtual HDs, torrent downloaders, diff tools, EXIF readers etc.). Porting this idea to LabVIEW I can think of codesets (OpenG, MGI) additional IDE enhancements (G#, JKI Right Click Framework, or a toolbar framework). Additionally NI has added things that could have been in a community patch (the Project environment for instance). What would we want in such a toolset? Ton

Using a full service (like Bucket, Kiln, Google Code, Microsoft codeplex or Sourceforge) has quite some advantages, it allows you to grant access to other people, use an issue tracker and setup a front page for your project. Ton

Make sure you have the correct settings in your configuration files (global:mercurial.ini or local:.hg\hgrc): [merge-tools] LVMerge.args = $base $other $local $output LVMerge.executable = C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe LVMerge.gui = True LVMerge.binary = True [merge-patterns] **.vi = LVMerge **.ctl = LVMerge **.lvclass = LVMerge **.xctl = LVMerge **.lvlib = LVMerge (for some reason I missed the dash in merge-tools) Perform the following steps: Right click on one of the branches, select 'merge with local' Hit 'Next' in the Prepare to Merge dialog In the next dialog a note is shown '1 files were modified in both branches and must be resolved', click on the underlined resolved The Resolve conflicts dialog pops up. In the bottom theres a dropdown menu named 'Detected/merge diff tools', select LVMerge. Highlight the conflicting file in the Unresolved items list Use the Tool Resolve button This will launch LVMerge, which will launch the LabVIEW resolve utilities. I'll post a HowTo on the LabVIEW Wiki Merge with TortoiseHG page. Ton

I detected that Mercurial has a commandserver/pipe interface, after some debugging I got a stable 38 msec per call for the most basic call, (coming from 150 msec) so that speed improvement is pretty good. Here's the code I ended with: Do you know what the overhead per dll call is? Ton

If I'm not mistaken it's quite normal for companies in the US to claim all products of a employee. [citation needed]. Some discussion here. I've never dealt with this since my employer isn't interested in the code I generally write as Open Source. There are some statements in our CAO (collective working agreement) but so vague that both the parties can make a valid claim. Ton

One thing it might be is that if an error occurs you stop reading the next items. So if your item isn't a mail item (rather an appointment) you will stop reading the other items. Ton

Get terminal name is definitely wrong, just because it's correct in one case, it's not valid in all cases. (Chris mentioned typecast). Get data name is correct to me. The code is specifically used for variants, so if you want to use is, you should package the data as a variant, in that moment the name is preserved (however you can change it using OpenG code). Ton

My blog is at: http://tononlabview.blogspot.com/ The RSS is at: http://tononlabview.blogspot.com/feeds/posts/default I don't write regurlarly, however things and bits I encounter will be posted there. I plan to write tutorials as well on that blog. Ton

I'm not sure, however using a cast can lead to unforseen results (for instance instant memory issues) Nope, the 'False' is only for the top level element (cluster), and not for any objec tinside the cluster. Ton

I would like to see OpenG version of the default 1,2 and 3 button dialogs offered by LabVIEW with an optional timeout. The purpose of such dialog is that it informs the user and allows him to take some action. If the user does not respond in time a default action would be taken. The timeout should default to '-1' meaning a timeout would never occure, the time-out would be configured in seconds, and the default button would show 'button-name[xxx]' with xxx in seconds until that action will be taken. Any thoughts? I'll try to come up with some protypes tomorrow. (perhaps an express VI) Ton

It's kinda sad to see that this LabVIEW bug isn't resolved after 4 years (and 8 updates),. Ton