Tomi Maila

This is some internal LabVIEW bug. Only the NI engineers have tools to debug LabVIEW internal code and locate the bug. You should contatc your local NI support for futher investigation. The ExecutionControl class is irrelevant for the crash, you should replace it with a single main VI to make it simpler for NI engineers to locate the bug. Provide step-by-step instructions how to reproduce the crash, which LabVIEW version you are using and which operating system are you using. NI engineers try to find you a warkaround if that's possible, at least if you have a support contract. Even without a support contract you should submit the issue to local NI support as it's a LabVIEW bug. Tomi

QUOTE(Paul_at_Lowell @ Jul 28 2007, 03:32 AM) Eh, there is not a main level VI in the example. Pehaps you should have an example that is runnable as well i.e. there is a main level VI. Tomi

I guess this is me then... http://forums.lavag.org/index.php?act=attach&type=post&id=6477

QUOTE(Justin Goeres @ Jul 23 2007, 11:14 PM) Congrats for the recent distractions Justin I bet this is not a personal ad for desperately searching for a date

QUOTE(orko @ Jul 23 2007, 10:05 PM) Thanks. If you really like it, don't forget to press the digg button below the article and submit it to digg.com. This way I get more visibility for the site and better google ranking eventually p.s. You should email your employee and use my video as an example of how their current 'security' policy is preventing your from doing your normal work.

Expressionflow Article: LabVIEW Object-Oriented Programming, or LVOOP for short, has been around for about a year now. Have you had time to take a look at it? If not, it's about the time. I made you a short video on the very basics of LVOOP development process. It doesn't go into details of inheritance and all that but it gives you and idea on how to get started. LabVIEW Object-Oriented Programming Introductory Walktrough

QUOTE(crelf @ Jul 22 2007, 04:27 PM) I'm a coffee guy as well. Actually I just received my new espresso machine from an Italian web store. It's just heating up. And it really makes such an excellent espresso, latte and cappucino. I must admit I'm a coffee geek, luckily there are no Starbucks in Helsinki where I live

Works for me from Windows Explorer and from LV Project Explorer for at least LV build-in xnodes in LV 8.2.1. Tomi

QUOTE(Aristos Queue @ Jul 19 2007, 12:35 AM) I've understood that all ancestor classes need to be in the project explorer during the development of any decendent class. I may have misunderstood. Am I wrong here?

QUOTE(Paul_at_Lowell @ Jul 18 2007, 10:36 PM) When working with LVClasses, all classes used need to be added to the project. LabVIEW doesn't automatically do this for you, not even when some classes you already have in the project inherit from some parent classes. So you need to manually add the parent classes to the project. The classes you need are under path <user.lib>\_OpenG.lib\openg_object. Simply add OpenG Object to the project. Then once in project, open the class and you'll see the available methods. I'd really like to see LabVIEW to automatically add the available methods for particular class to the context menu of a class wire. AQ, are we seeing this anytime soon? p.s. Aristos Queue, nice to see you here more often again. I guess you are less busy with your projects now Welcome back. Tomi

QUOTE(Gavin Burnell @ Jul 18 2007, 06:05 PM) Actually OpenG Object contains methods that extract the Class runtime name using this method. It does do it the proper way. Should you need the functionality, simply install OpenG Object package with VIPM and see the source. Tomi

What about LabVIEW Object-Oriented Dataflow (LVOOD, pronouced 'Elwood'). Tomi

QUOTE(Michael_Aivaliotis @ Jul 17 2007, 09:13 PM) I liked the LOOP acronym that was suggested by some people before LabVIEW 8.2 was released.

Actually it's a recurring problem to select action based on what class your object is of. Consider for example that you receive a message object from some message source and you need to make a decission of next action based on the message type. The typecasting trick works fast and very well when there are only one or few classes you need to match agianst or message types in our example case. However when the number of cases increases, the code becomes easily a messy as you need first to check if the message is of type A and then to check if message is of type B and so on. Classes that use OpenG Class Templates for LabVIEW Object-Oriented Programming can take advantage of OpenG Object method "MatchRuntimeType". This particular method allows users to easily check if the object is of some known type and select action based on the matched type. This functionality is called Pattern Matching in object-oriented programming. In the image below the user has some object which is Child B in this particular case. In the code, the user needs to select action based on the type of the class. Using MatchRuntimeType method of OpenG object, this particular task is very simple. User simply needs to create a type array of all classes for which there is a different action and wire the type array to MatchRuntimeType together with the object of unknown type. MatchRuntimeType returns the index of the first class that matched the object. Parent class matches all it's child classes. If no matches were found, -1 is returned. The returned index can then be wired to case structure to select action based on the matched class. http://forums.lavag.org/index.php?act=attach&type=post&id=6381 Note that this method requires that all classes are based on the OpenG Class Templates.

<cite>QUOTE(crelf @ Jul 17 2007, 05:30 PM) </cite> <img src="http://forums.lavag.org/style_images/1/folder_editor_images/rte-switch-editor.png"> <cite>QUOTE(crelf @ Jul 17 2007, 05:30 PM) </cite> I tried doing what you said using the "toggle HTML source" button and it didn't work - do I need to click "Save HTML" as well? I don't have any Save HTML button... I only have 'Add Reply' and 'Preview Post' buttons under the Post Options and Post Icons bars. Tomi

What I did was following: - Press toggle rich text button - Set HTML On - Auto Linebreak Mode - Paste embedded video HTML - Press preview <object width="425" height="350"><param name="movie" value=" name="wmode" value="transparent"></param><embed src=" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

Below the LAVA post editor is a "Post Options" pull-down menu. Select either of the HTML modes. Then just type in the HTML tags. I'm not sure if you need to turn off the rich text editor, by pressing the Toggle Rich Text Editor button in the upper right corner of the editor. p.s. HTML tags are permitted only for premium members if I recall correctly. I'm not sure if Mike regards you as such.

QUOTE(rolfk @ Jul 11 2007, 12:56 PM) What an excellent suggestion. I guess the following sequence needs to be executed for this particular task Reserve a block of memory referenced by a pointer p Copy content of a LabVIEW array excluding the size specifying bytes to the newly created block Call first proprietary C function and pass the pointer to this function Copy second proprietary C function and pass pointer p to this function as well Create a new array handle and copy the content of the memory block referenced by p to the memory block of this handle after the size bytes Set the size bytes of the array handle to the proper values However I'm not sure if this task can be safely implemented within LabVIEW only. The set of memory manager functions is limited and pointer referencing and dereferencing is a challenging job within LabVIEW. Multiple calls to LabVIEW executable are not atomic in a sense that LabVIEW guarantees the memory buffers to remain the same for each call. As a result it's hard to properly manipulate LabVIEW array handles from within LabVIEW. Even when current version of LabVIEW doesn't make a buffer allocation in certain place, there is no guarantee that future version of LabvIEW will act the same way. I'm familiar with using LabVIEW memory manager functions in external C code and still this task seems challenging for me to complete using only calls to LabVIEW executable. On the other hand the task is relatively easy if one simply writes a few lines of C code and compiles that into a shared library (DLL).

QUOTE(Aristos Queue @ Jul 10 2007, 10:12 PM) One reason might be that when LabVIEW crashes often without obvious reason without any obvious reason and you have reported dozens of bugs within the last year, you just get tired of troubleshooting every crash and go on...

You cannot guarantee that memory block reserved by LabVIEW stays in the same memory position between multiple DLL calls. LabVIEW guarantees only that memory block stays in certain memory position for the time of the DLL call. To have a block of memory that stays in certain memory position, you need to reserve and release the memory within the external code.

QUOTE(eaolson @ Jul 6 2007, 08:46 PM) Queues don't have the same issue. This issue is notifier related only.

QUOTE(Jim Kring @ Jul 6 2007, 05:38 PM) If there is a call chain of a subVIs calling other subVIs and so on, the only safe way to use Wait for Notification is to have all the subVIs in the call chain to be reentrant.

QUOTE(LV Punk @ Jul 6 2007, 02:32 PM) Another important thing to remember with notifiers is that a single "wait for notification" (W4N) node should only be used with a single notifier reference only. As a result W4N nodes should not be used in subVIs that could be called from multiple different parts of any application. The problem with W4N nodes is that they ignore all notifiers send before the last notifier they received. Therefore if a single W4N node is used with multiple notifier references, for example when W4N node is in a subVI, the notifier being processed may be actually sent before the previous notifier handled. As a result the program may hang. So if you are looking for a thread safe way to do things, queues are definitely safer way to go. If you feel you are absolutely familiar with this counter-intuitive way W4N nodes work, then go ahead and use them. I've not used notifiers since I found this odd behaviour and I guess I never will. Link to the thread that covers the inner secrets of how notifiers actually work http://forums.lavag.org/Notifier-signals-missed-t4220.html''>http://forums.lavag.org/Notifier-signals-missed-t4220.html' target="_blank">http://forums.lavag.org/Notifier-signals-missed-t4220.html Tomi

When you preview a queue element and there is no data in the queue, then the preview operation waits data until timeout. If there is still no data when the timeout occurs, preview queue returns timeout. The value returned when timeout has occurred has not been specified. Tomi

What kind of thread safety are you expecting actually? What is the use case where you need thread safe queue access? I ask because there may be use cases that are not implementable without external semaphore mechanism. Consider for example that you want to have a queue that has always two elements and you want always to preview the second element. Still you want to be able to remove the elements and add new elements to the queue. Even though the queue is thread safe, you cannot guarantee that there always is two elements in the queue when you try to preview it. Therefore if you would like to guarantee that there always is exactly two elements in the queue when you preview it, you would need to have another semaphore mechanism. The best semaphore mechanism I know of is a (single sized) queue itself Tomi