Olivier Jourdan

I'm not trying to convince ShaunR, I'm just sharing my experience with OOP I've been working with LV for a few years now, and moving to OOP has been for me a great thing. That's not a reason to not understand ShaunR argument. I've"liked" is post, anyway I think is way of thinking reach limits when you work in a team.

One thing that OOP helps to solve is the team work. OOP has "rules" that you must follow, when these rules are well known, you reduce dramatically the need to write documentation on how access data, how share source code, how organize your VIs, etc... Also rules are better followed when they come from "nobody" (OOP is not a guy in your team) than if they come from one man in a team. This avoid most of quarrel in a team...

I was thinking about doing this font change, but I'll wait to see if there is feedback on this issue to decide if it's worth the work (there is almost 100 VIs to modify !) Anyway, thank you for sharing your idea. Olivier

Just to give an update, the last version (1.2.0.18) of the package is now available through VIPM Community edition

Good thing to move to the Mac I'd recommend you Pixelmator it's not free but it really worth the few dollars and the app is really well integrated with OS X environment.

You're right. It doesn't work

Great work Ravi! I've got some ideas about your tool. Use All VI in Memory property could be interesting to access all VI without editing code. To avoid selection issue when lot of VIs are in memory, adding a filter to the VI list could be sufficient. An other way I'm thinking about to built the VI list is to use almost the same thing we use in SAPHIR "Chronograph" probes. If we can list the VI where a probe is open, you could easily build the VI list to pause. I think it can be a good solution between "All VI in Memory" and "adding code". The only matter is that as far as know we are not able to know in which VI the probe is open Anyway, it's the first time I heard about this debug need, but it's really challenging probe designing

Here it is ! You can download the last version of SAPHIR probes (I hope that the update will be available directly through VIPM next week). The package contain the new probes presented in this post, with a few enhancement. We've also added probe named Chronograph. As the one presented in this post by MikaelH, Chronograph probe allows you to measure time between it and any other SAPHIR probes. It could be very useful for a quick code execution time checking. Finally, we've tried to standardize every probes ui in order to have resizing capabilities and add "freeze" and "clear" graph button when it was necessary. Hope you'll enjoy this new package. If so, feel free to leave a comment here. Note about ui rendering on Windows Seven : Probes was originally designed on Windows XP. Using them on Windows 7, we've came across some ugly ui rendering following OS display settings. You can see the worst example below : History probe under XP : Same probe under 7 : We've tried to mange it as best as we've can, feel free to give us feedback on this point. Olivier. saphir_lib_vibox_probes-1.2.0.18.vip

What a nice compliment Thank you for sharing that. We also have this kind of probe. To package it, I'm wondering which type of queue we need to handle ? String and Variant cluster is essential, but is there other useful type that should be addressed by this kind of probe? I'd be curious to know developers opinion. Olivier

Hello, I'm currently updating our probe add-on with really awesome probes designed by a colleague who need to deals with 1D or 2D array and string display. The goal is to obtain an easy and quick way to display and navigate array with the possibility to monitor more than 1 array element. In addition we have had the capability to string probes to change the display from normal to hex or code display. You can see a small demo on this video <object width="560" height="441"><param name="movie" value="http://www.dailymotion.com/swf/video/xktiqq?width=560"></param><param'>http://www.dailymotion.com/swf/video/xktiqq?width=560"></param><param name="allowFullScreen" value="true"></param><param name="allowScriptAccess" value="always"></param><param name="wmode" value="transparent"></param><embed type="application/x-shockwave-flash" src="http://www.dailymotion.com/swf/video/xktiqq?width=560" width="560" height="441" wmode="transparent" allowfullscreen="true" allowscriptaccess="always"></embed></object><br /><a href="http://www.dailymotion.com/video/xktiqq_newstringprobes" target="_blank">NewStringProbes</a> <i>par <a href="http://www.dailymotion.com/SAPHIR-Videocast" target="_blank">SAPHIR-Videocast</a></i>

I agree, it's not a technical issue, but it could be philosophic debate or more simple a big change in our usual day to day OpenG usage

Hey JG, related to the question of location in the LabVIEW hierarchy I guess that you need to think about the palette location. National Instruments ask us to move our toolkits from custom SAPHIR palette to existing category (i.e Connectivity, Data communication...) for future LV2012 Compatible for LabVIEW program. Other possible place could be Add-ons palette if you want to keep VIs in OpenG palette. Olivier

I know that CC is often used by photographs (Flickr give an easy way to add any CC contract to your pictures). Could it be used for software, I don't know. Anyway they've done a great job to help to understand what you can do or not. in addition to the 3 layer approach, they have translate text in a lot of different langages and it's really helpful to avoid misunderstanding

I agree with the simplification trend. Perhaps it would be nice to add examples about how to reference Openg in an application and in a toolkit ? These examples would be much more comprehensive than "legal" text contain in Software License Agreement. A link could be displayed at the end of the OpenG package installation ? Olivier

Great ! Thank you for your work Olivier

From "Explain error" window (LabVIEW Help menu): Not easy to tell more about without more contextual explanation. Olivier