burd

Hello James, Since I started using the framework I started having trouble with the so called Infinite Reset of Death during shutting down of the application (executable). The cause of the problem is not the messenger library, and now there is a way to deal with this problem as explained here: http://www.labviewcraftsmen.com/blog/not-so-infinite-reset-of-death I used the methodology and it works very well! Now there is no more possibility for the resetting VI message that never goes away during shutting down of the application. I hope users of the messenger framework find this useful.

Porter, Wouldn't the performance hit only be limited to the time period during the creation of the muParser if you use the solution which recursively look for the libmuparser-x32-lv.dll ? I believe that it should not exist performance hit after the creation of the muParser in the above case. I would imagine that after the creation of the reference it won't be necessary to look again for the libmuparser-x32-lv.dll if one keeps the reference to the muParser opened. Do you agree?

I figured out where the error was coming from, The mupLibPath.vi is unable to find the correct location of the libmuparser-xxx-lv.dll if it is not in the same directory as the executable. I fixed it by adding something more generic that will try to find recursively the .dll file within the folders of the project, so I do not have to worry about placing the .dll together with the executable (see picture). If someone likes the idea and want to use it, I put the VIP file that will allow to look recursively for files. I hope that this might be useful for someone, thank you for the help! helcio_lib_folder_utilities-1.0.0.6.vip

I added the libmuparser-x32-lv.dll to the project and then specified it in the source files/always included section in the build spec (see figure below). However I continue getting Error when I run the executable file. I am getting Error 7, file not found coming from muParser Vis (see below); Any idea of what I could do to fix this? Thanks

No, I did not do that. I will try! Thank you so much for the information! muParser is a great library, I was very sad that I would have to give it up, but now I am happy again!

I am having trouble when I building an executable that contains muparser Vis. The reference to it is getting deleted (Error 1556; LabVIEW: The reference is invalid. This error might occur because the reference has been deleted.) even though the application works fine in development mode. Do I have to copy any DLL to the Data folder of the executable? I am using labview 2017; thanks

Dr Powell, How do I find out if there is no return address attached to the original request message? thanks

I got very confused because the VI Help for the Metronome Actor says that this actor accepts the Shutdown message (if I remember right) and not Shutdown Actor message as you said. It is necessary to update this help menu if that is the case. For creating help for vis, I usually use the VIHELPKS that I recommend for that, as it automates the boring process of creating help files. Thanks for the information Also that you for helping with the Issue#9, It is fine just to have the topmost actor as Re-entrant, if it is the only way to make everything work, though it is annoying indeed!

Hello Dr Powell, I would like to thank you again for this great library. I use it in all my projects and I am very happy with the flexibility it brings to my work. There are 2 weird small problems, though not really critical, that I found in the most recent version the Messenger Library: Problem 1: If you create a metronome Actor, the only way to shut it down is by sending a message Macro:Exit If I send a message Shutdown to this Metronome, it won't shut down. This has been happening since version 1.8.3.82 (I started using this version). Problem 2: I am currently working in a project that uses the messenger library 1.8.3.82 then I did an upgrade for the messenger library to the version 1.9.2.90. After the upgrade (In Labview 2017), the project opens without any problem (no broken arrows). However, when I execute the main VI, none of the LAUNCH ACTOR work properly; There is a message saying to open the actor and see if the vi is able to execute but all the actors are fine, even the main actor (no broken arrows) . The only way to make it work again after the upgrade is by saving the main Actor (which does not need to be Re-entrant) as re-entrant and changing the the vi properties to shared clone in the VI Properties menu. After that everything works the same as 1.8.3.82 I hope these information help to improve the Messenger Library Thank you! mass compile errors.docx

I tried to login too, but no connection!

Hi Michael, The ones you marked in red were the problem. Good to know that most of the utilities work for Goop4 classes! Thank You! Helcio

Hello Mikael, I wonder if the VIs in the GOOP Utility pallet work for GOOP4 classes in the version 1.0.37[37] which is the version I am currently using. I seems that it does not because I get errors when using them. Did you fix them so that they can work with GOOP 4 classes? thanks Helcio

Ok, I will check that! thanks

Re: Design Patterns Hi Mikael, When I run the remoteloader.vi in the CommandPattern project I get the error 1100: Obtain Queue in RemoteControl.lvclass:GuiRepository.vi->RemoteControl.lvclass:ControlGuiWindow. vi->RemoteLoader.vi I am wondering if this error has anything to do with the labview version I am using (2013). thanks Helcio

Try to install the VIPC file again (https://decibel.ni.com/content/message/75586#75586), something went wrong with the previous upload. I updated it, now should be fine..

Hi Mikael, I have completed the abstract factory pattern. I am sending attached for anyone to look and comment. I realized that I actually do not need to know the reference to a class is empty. If the class wasn't instantiated, the abstract method parent class executes (in the method toString in Pizza.class, the parent method of classes Sauce, Cheese, Dough, etc will be called in case these classes were not instantiated) resulting an empty string. Would be nice to have the tool to know of the class was instantiated, but I prefer to wait until you to complete the Utilities for goop 4 classes, looks complicated. The files are at https://decibel.ni.com/content/message/75586#75586 because they are too big to upload here. regards Helcio

Hi Mikael, I have just read the post, thanks for the tip! The GOOPUtil_IsValidReference.vi is exactly what I need but unfortunately I use Goop4 classes Is there anything for goop4? regards

Hi Mikael, I am trying to build the abstract factory pattern with GOOP and I do not know how to check if an object reference is not empty in Labview. In JAVA this was done like this: How can I do this in labview?

Hi Mikael, Your solution is very elegant! I liked that the create vis can be used also to put constructors in it: and also I leked the way the class item icon in the project explorer mirrors the class hierarchy: blue for Beverage classes, red for condiment classes, frame for abstract classes and full for concrete classes: Thanks a lot for the solution! Helcio

Hi Mikael, I am trying to build the Starbuzz example in the Head First: Design patterns using Goop. I have had partial success and this vi works: However, something goes wrong when I want, for example, double soy or double mocha, etc. Could you help me to figure out what is going on? This is the project containing all classes and main vis: Decorator Patterm with GOOP.zip Thank You!

Hi Mikael, I built an observer pattern with Goop: I basically followed the Weather Station example in the Head First: design Patterns: I used the goop's interface template and the interface implement design pattern for the observers, but I think it would also work just fine using abstract class for rather than the interface. Here follow the the files (Observer Pattern GOOP.zip) and If you or anybody else have any comments, please, let me know. thanks

Hi Michael, That makes sense and everything works just fine now. Thanks!

Hi Mikael, I have been scratching my head...... I have been looking further into the 1556 error in the Duck Main.vi (attached) which claims that the reference is not valid. But if I clear this error, everything works just fine, as the reference refers to an object which exists in memory and the reference seems, therefore, to be perfectly valid: The error is generated just after it verifies if the reference is valid using the Not a Number/Patch/Reference function. I looked in the Help for this function and it says cannot be used to check for the validity of refnums created by Goop Wizard: Is this a bug in Goop? Thanks! Helcio Here is the Duck3.zip