vugie

Here we have 2 brothers and one sister: 3dex.vi

Like AQ said - children of the same parent are independent. You shouldn't think about SceneObjects as about real objects. they are rather nodes. Not all of them must have visual representation (Drawable). There is one node which is a "root" ant it may not be transformed at all, neither be tighten to any visual object. All other objects are its children (not necessarily directly). If you want to make group of objects move together, or share some properties, just create a common parent for them. You should also differentiate transformations from changing properties. Transformation is only geometrical movement (translation, rotation and scale). Changing color to blue is only changing the color property. Transformation of parent object always transforms children as well (however all transformations are relative, so it is only a kind of visual impression). Most properties of nodes along with their actual possible values have one called "Inherited" and usually it is a default value for new nodes. It means that actual value of certain property will always be the same as for its parent. This is why you observed changing colors for all the spheres.

I didn't explain it well... From the start. Sandbox has defined "scripts" directory which is scanned to find installed scripts (by script I mean a VI where Active VI data is passed to). There is "New Sandbox VI" option which automatically creates new script from the template. It is a new unsaved VI, just like after clicking vit file. After creating the script you want to save it, but by default save dialog starts at directory of previously saved VI (or sth like this). So you have to remember where your scripts directory is and search for it. It may be a pain when it is located somewhere deep, so it is in conflict with "quick&dirty" paradigm of Scripting Sandbox. Summarizing, I'm programatically creating new VI for edit and I want to have specified directory in save dialog when user presses Ctrl-S

I added documentation for script template (as BD comments). Does anyone know how to set default directory for save dialog? Just for convenience when creating new script - dialog would automatically point to scripts directory.

Here is an example of how to create and use callbacks.

I uploaded a VIPM package of Waptia library.

I uploaded a VIPM package and updated naming convention for ZIP

Irrlicht engine has .NET API Axiom is a .NET port of OGRE I didn't use them. Just know they exist

The only reason is that it was submitted in pre VIPM 2010 age. Please just send me the package and I'll add it to download. And thanks for the effort.

What you guys have against auto tool?... I use it all the time with only exception for picking colors (BTW it is ^$**#^#*#$@%$)

New fancy 3D charts. Do you also and when you accidentally put one of them on the front panel?

There is one thing which is able it cover it. It is... another 3D Picture control.

Of course I knew that. Small boolean constants and blue scripting headers confused me. Thanks for the effort on behalf of all people tied to older (but still good and usable) LV versions.

Not related question: Why all snippets you post have header indicating 8.2 version regardless of version you actually created them in?

The purple VIs in Get Frame.vi are part of MemBlock library and they simply call MoveBlock function. I fully agree

Or just Ctrl+PgDn in Total Commander Quick look into spec file gives you sufficient information what to do Ok, I saw the emoticon...

In fact, it is more convenient. But (just to make things clear) - the buffer is still copied here, so (taking into account typical sizes of frames) there should be no performance differences between both versions.

I don't have it, as it is a part of camera SDK provided by manufacturer. I only call the DLL. It takes a pointer to a callback function which is (internally by SDK) called each time new frame arrives. I made separate dll which contains only the callback function I listed before.

This is very common issue for writing camera drivere. Here is my solution (for iCube camera): Callback function: DLL void iCubeCallback (char *pBuffer, int IBufferSize, LVUserEventRef *eventRef){ struct tBuff { char *pBuff; int size; } buff; buff.pBuff=pBuffer; buff.size=IBufferSize; PostLVUserEvent(*eventRef, (void *)&buff); } Initialization: And Get Frame.vi: Do you know any undocumented functions for that?

Thank you Rolf for bringing this thread up. Although current solution works, I'm not much satisfied with it. BTW, now I can say that it is for lvODE library I published recently. This is how the error handling is currently implemented: The C part first. Error handler (this function is passed to main DLL to be called in case of error) and GetLastError function: DLL void lvodeError (int errnum, const char *msg, va_list ap) { lasterrnum=errnum; vsprintf_s (lastmsg,256, msg,ap);}DLL int lvodeGetLastError (char *msg){ int temperr; if (lasterrnum==0) { return 0; } else { strcpy_s(msg, 256, lastmsg); temperr=lasterrnum; lasterrnum=0; return temperr; }} lasterrnum and lastmsg are previously mentioned statics. Abort() is commented out in main DLL. During Initialization I get address of error hadler and I pass it to main library (ode.dll): LabVIEW part of GetLastError - not much complicated: Typical call to main DLL: So GetLastError should be called after each CLFN. As I'm still testing it, it is not put there now. But as abort() is commented out (and I guess it is a must) and parts of code may run concurrently, I have doubts whether GetLastError will always get the error in right place...

Maybe it could be somehow realizable with OpenG Pipes... Just loose thought.

I'm absolutely serious. Colored wires (not overused of course, not too fancy and well suited to icon colors) help me to keep block diagram clean and understandable. I seldom use LVOOP for whole application architecture, because 90% of my programming is prototyping solutions and I agree with what Jason said: changing the architecture based on LVOOP is a pain. I use classes mainly for well defined data types, often strongly related to real-world objects, not suspected to change too much and not too much dependent on other data types. So I mainly take advantage of encapsulation and wire colors play a main role here - I have up to several classes in whole the code and I just remember these colors. If I sometimes don't remember I know that they are related to headers of class methods icons. When I have slightly more complex inheritance hierarchy, I vary colors of children wires little bit. I found that in general aesthetics is a one of most important factors which make (at least for me) programming in LabVIEW efficient and just a pleasure.

I'm not motivated enough to carefully read whole the discussion, so maybe it was put already. What I like the most in LVOOP is custom colors for wires. The effect is worth the effort for implementing all these access methods...

That is how I understood it. After double-clicking TC extracts the clicked file to temp directory and launches it. And this behavior cannot be changed with plugin. As for top level VIs I currently display them as they have "system" attribute, so they appear in different way. I don't know now how it will work with copying files to LLB.