Double dynamic dispatch

I'm just throwing an idea out here for a moment.....
I'm fiddling about a bit with OOP at the moment (LVOOP to be precise) and I'm wondering if I can use it in a semi-nice way to do a certain task.
I was wondering if it's possible to have a VI which takes an instrument class as an input (with Dynamic dispatching) and accepts a second class as secondary input (also Dynamic dispatching). This would most likely mean I need a lot of VIs to cover all Class 1 & Class 2 options, but that's do-able.
I'm toying with ideas still stemming from my nugget a while back. I basically have a family of instruments (spectrometers) which have different parameter sets which I would like to have settable independently of each other. It would be quite nice to have a single "set" function accepting two classes (one for the instrument, one for the data to be set), then causing the correct routine for this data set to be called without me having to parse strings, variants or anything like that.
The LV help says "Note Although a dynamic dispatch member VI can have no more than one dynamic input, the VI can include multiple dynamic outputs" but I was wondering if there's a workaround to allow something of this kind.
Of course I could just try things out, but that'd take me quite a while as I'm not yet very proficient with LVOOP.
Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

Thanks for the help,
I have already implemented a small LVOOP routine, and it sure made sense when I was writing it myself. But I downloaded some examples (LV2OOP) and I found it downright confusing. I feed like a real n00b!
I'm convinced there are some really powerful uses for it, but I just don't have the same feeling of "I know this" as with other areas of LV. I've been working with 6.1 until recently. I think I need some courses. Learning from zero is easier than re-learning stuff you thought you'd already learned.....
I can only imagine others feel the same way. Some way to highlight what's going on behind the scenes with a LVOOP project would probably go a LONG way to converting people.
Again, thanks
Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

Similar Messages

Combining LVOOP DVR with Asynchronous Dynamic Dispatch and Preserve Run-Time Class

OK, the title sounds like a cornucopia of LVOOP terms. But there's a reason. This is in a way an extension of THIS thread.
What I'm doing recently is creating a LVOOP approach to loading Completely Asynchronous UI elements into subpanels. This I have combined with a global repository for the objects (which are essentially singletons with a UI functionality) which are shared via DVR, thus eliminating a lot of synchronisation headaches).
This means that I can ahve a universal framework for launching the UI elements into a subpanel. The changes made on the Object there are automatically reflected in the global repository.
So far so good.
What I don't like too much is a combination of two seemingly awkward code constructs I need in order to keep things running.
Weird construct 1:
I have defined a "Launch UI" function in my parent class which is Dynamic Dispatch (Allowing each object to take care of launching its own UI). This takes a parent object DVR as a second input which I make sure is of the exact same type as the object type being invoked by using the code shown below. The ACTUAL Type of both inputs to the launch VI within the IPE are identical. This is guaranteed because I require each new class to override this function.
Here I pass the DVR from outside the IPE to the "Launch" VI but the Object obtained within the IPE retains information required for DD thus ensuring that the VI called for launching the UI is identical to the ACTUAL object type in the DVR. This works OK and by placing this weird construct WITHIN the parent class, abuse is minimised, it works fine and seems to have no major side-effects.
So now we have a VI running asynchronously in the background which belongs to a specific object but has a DVR which it *thinks* is of a Parent Type but, because of the steps taken earlier, is actually of the same type as the object itself.
In order to make use of the functionality defined in this actual object type, I need to continuously re-interpret the Object within the IPE as shown below. Otherwise only the Parent functionality is available.
If I am accessing only methods of the parent class, then the Preserve functionality is not needed.
Is there a more elegant way to do this? I find the net result of this code and type-juggling to be really useful and much easier to manage than the non-DVR route since the synchronisation issues disappear. By making the IPE usage near-atomic we remove the chances of deadlock.
All editing done in the UI of the asynchronous VI is reflected automatically in any subsequent usage of the DVR. Even if the DVRs are not shared between VIs, this makes (for me) the headache of synchronisation easier. If you start expanding this beyond the limits of a single VI, the benefits in Synchronisation become really huge. You can even have multiple UI objects operating on the same data in the background without extra synchronisation needs. The only synchronisation required is a global "Data updated" for the object in question whereby the UI elements simply update their indicators and controls from the DVR again. This is trivial.
Thus I am convinced that the net result of this is very beneficial.
My question is if there's a better, safer or more "official" way to do this?
I was about to start a new Idea for combining the "Preserve Run time Class" and the DVR Terminal of the IPE so that the casting is done automatically. We could then have a double input to the IPE, the DVR (of base type) plus the ACTUAL Type of the object but of course returning an error if the types are incompatible. It would be like an "Imposter" DVR input for the IPE which allows a re-interpretation of the object type.
Would all of this go away if we allowed Dynamic Dispatch to work with DVRs? Probably.
Shane
Say hello to my little friend.
RFC 2323 FHE-Compliant
Solved!
Go to Solution.

You guys rock!
I didn't even think of casting the DVR like that. Kinds stupid of me but I never would have thought it would work. Cool.
Also, Yeah, the limitation of no IPE in the Launch VI was one I spotted quite early on. this is why my Launch VI also doesn't accept more data than is absolutely neccessara because a DVR access in that VI will of course cause a lockup. I have the system so far now that I can have a SINGLE Launch VI (Which is NOT overridden, so the limitation refers to only a single VI now which is certainly better.
So again guys, thanks for helping out an old newbie. I've been around for quite a while, have made many posts but I love the way I just keep learning from others in the Forum. This is just why I absolutely LOVE it here.
Shane.
Say hello to my little friend.
RFC 2323 FHE-Compliant

OOP debugging dynamically dispatched VI

I'm using OOP to create a hardware abstraction layer (it's secondary to this question but search for "How to Mitigate Hardware Obsolescence in Next-Generation Test Systems" and look at version 2) and backed myself into a corner. My code stopped at a breakpoint on a dynamic dispatch VI and I stepped into the dynamic VI. After stepping partway through the VI I accidently closed the dynamic VI, with execution paused in it. I couldn't find a way to get back to the paused block diagram to continue (double clicking on the VI call allowed me to opened a clean copy of the VI, but not the paused copy). Is there a way to regain control short of killing everything and starting over?

You can open a reference to the clone and then use a property node to open its FP or BD. To open a reference to the clone use a for loop and open a reference to My Class.lvclass:My VI.vi:X where My VI is your VI's name and X is a running number starting from 1 and going up to something (I would suggest a while loop you stop manually). One of these numbers will be the number of your clone (they are assigned when the clone is created in memory, so you can't know it in advance. Also, be sure to ignore the errors in the loop, as you will get them for all the clones that don't exist.
Try to take over the world!

Problem with combination of LabVIEW classes (dynamic dispatch), statechart module and FPGA module

SITUATION:
- I am developing a plug-in-based software with plug-ins based on LabVIEW classes which are instanced at run-time. The actual plug-in classes are derived from generic plug-in classes that define the interfaces to the instancing VI and may provide basic functionality. This means that many of the classes' methods are dynamic dispatch and methods of child classes may even call the parent method.
- Top-level plug-ins (those directly accessed by the main VI) each have a run method that drives a plug-in-specific statechart.
- The statechart of the data acquisition plug-in class (DAQ class) calls a method of the DAQ class that reads in data from a NI FPGA card and passes it on to another component via a queue.
PROBLEM:
- At higher sampling rates, an FPGA-to-host FIFO overflow occurs after some time. When I "burden" the system just by moving a Firefox browser window over the screen, the overflow is immediately triggered. I did not have this kind of problem in an older software, where I was also reading from an FPGA FIFO, but did not make use of LabVIEW classes or statecharts.
TRIED SOLUTIONS (WITHOUT SUCCESS):
- I put the statechart into a timed loop (instead of a simple while loop) which I assigned specifically to an own core (I have a quad-core processor), while I left all the other loops of my application (there are many of them) in simple while loops. The FIFO overflow still does occur, however.
QUESTION:
- Does anybody have a hint how I could tackle this problem? What could be the cause: the dynamic dispatch methods, the DAQ statechart or just the fact that I have a large number of loops? However, I can hardly change the fact that I have dynamic dispatch methods because that's the very core of my architecture...
Any hints are greatly appreciated!
Message Edited by dlanger on 06-25-2009 04:18 AM
Message Edited by dlanger on 06-25-2009 04:19 AM
Solved!
Go to Solution.

I now changed the execution priority of all the VIs involved in reading from the FPGA FIFO to "time critical priority (highest)". This seems to improve the situation very much: so far I did not get a FIFO overflow anymore, even when I move around windows on the screen. I hope it stays like this...

Variable size array output from dynamic dispatch class method on FPGA

I have a Parent class on the FPGA that will serve as a template/framework for future code that will be developed. I had planned on creating a child class and overriding a couple methods. The child class constant would be dropped on the block diagram so the compiler wouldn't have any trouble figuring out which method (parent's or child's) should be used (i.e. the parent's method will never actually be used and won't be compiled with the main code). The output of one of the methods is an array. This array will have a different size depending on the application. I defined the array size as variable. In the child method, there is no question about the size of the array so the compiler should be able to figure it out. However, when I try to compile, I get an error about the array size. I can't figure out any way around it. Any thought would be greatly appreciated!
Thanks, Patrick
Solved!
Go to Solution.
Attachments:
FPGA Test.zip ‏1194 KB

Wait what?
Can we use dynamic dispatch VIs on FPGA? Really? I was completely unaware of this. Obviously the dependencies need to be constant and known at compile time but...... This would have saved me a lot of headaches in the last few months.
Since which LV version is this supported?
Say hello to my little friend.
RFC 2323 FHE-Compliant

The build specifications does not support VIs with dynamic dispatch terminals

Why?
Will it be supported in the near future ?

pacome wrote:
I wanted to build a shared DLL.
The problem occurs when an input Control is a dynamic dispatch terminal.
"Now that's a horse of a different color!" (Caby, Wizard of Oz, Emerald City Scene).
Yes the DLL spec never knew about dynamic dispatching.
Your best option is to wrap the LVOOP stuff up in wrappers and expose the wrappers.
I'm curious if others have ideas as well.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Dynamic dispatch too dynamic!

It seems that the dynamic dispatch feature in 9i is too dynamic.
Too dynamic because it's not possible to execute super methods
in an overridden method. In Java, the keyword "super" is used to
invoke the corresponding method on the super class, in C++ the
programmer can control which class' method is called by using
the class name.
I'm trying to accomplish this with PL/SQL. At OpenWorld 2000 it
was told that a keyword SUPER could be used to access the method
on the super class but I cannot find this in the documentation
and I've tried to invoke the given type's method directly, but
the dynamic dispatch goes into a recursive loop because it calls
the overridden method directly.
Some examples are in place here:
create or replace type person as object (
name varchar2(30),
address varchar2(100),
member function print return varchar2
) not final;
show errors
create or replace type body person as
member function print return varchar2 as
begin
return(/*super() ||*/ 'PERSON: { name = ''' || name ||
''', address = ''' || address || ''' }');
end;
end;
show errors
create or replace type student under person (
dept varchar2(30),
overriding member function print return varchar2
) not final;
show errors
create or replace type body student as
overriding member function print return varchar2 as
begin
return(/*super() ||*/ 'STUDENT: { dept = ' || dept || ' }');
end;
end;
show errors
create or replace type part_time_student under student (
numhrs number,
overriding member function print return varchar2
show errors
create or replace type body part_time_student as
overriding member function print return varchar2 as
begin
return(/*super() ||*/ 'PART_TIME_STUDENT: { numhrs = ' ||
numhrs || ' }');
end;
end;
show errors
create table persons of person;
insert into persons values (person('name', 'address'));
insert into persons values (student('name', 'address', 10));
insert into persons values (part_time_student('name', 'address',
10, 15));
select p.print()
from persons p;
In the PRINT method I would like to reuse the inherited method
by calling it and let it do it's work without me having to copy
the code to the overridden method. In other words, I would like
to be able to call it using SUPER() or something similar. But
SUPER isn't reckognized by the compiler so what should I use?
I've also tried to call the method directly, eg in
PART_TIME_STUDENT.PRINT call STUDENT.PRINT(SELF) but because the
dynamic dispatch is too dynamic this actually calls
PART_TIME_STUDENT.PRINT recursively -- endless loop :-(. I would
consider this as a bug because I tell the compiler exactly which
method I want to call, as opposed to O.PRINT where I invoke the
most specialized method on an object O.
How can this be done?
Thanks.
Finn Ellebaek Nielsen
ChangeGroup ApS

Finn,
It was an oversight, that 'super' didn't make it into the
release. The suggestd work around was to use the name of super
type explicitly as you have tried and failed.
Do you have a matalink customer id to file a iTAR? Let me know
if you don't have one.
Regards,
Geoff
It seems that the dynamic dispatch feature in 9i is too dynamic.
Too dynamic because it's not possible to execute super methods
in an overridden method. In Java, the keyword "super" is used to
invoke the corresponding method on the super class, in C++ the
programmer can control which class' method is called by using
the class name.
I'm trying to accomplish this with PL/SQL. At OpenWorld 2000 it
was told that a keyword SUPER could be used to access the method
on the super class but I cannot find this in the documentation
and I've tried to invoke the given type's method directly, but
the dynamic dispatch goes into a recursive loop because it calls
the overridden method directly.
Some examples are in place here:
create or replace type person as object (
name varchar2(30),
address varchar2(100),
member function print return varchar2
) not final;
show errors
create or replace type body person as
member function print return varchar2 as
begin
return(/*super() ||*/ 'PERSON: { name = ''' || name ||
''', address = ''' || address || ''' }');
end;
end;
show errors
create or replace type student under person (
dept varchar2(30),
overriding member function print return varchar2
) not final;
show errors
create or replace type body student as
overriding member function print return varchar2 as
begin
return(/*super() ||*/ 'STUDENT: { dept = ' || dept || ' }');
end;
end;
show errors
create or replace type part_time_student under student (
numhrs number,
overriding member function print return varchar2
show errors
create or replace type body part_time_student as
overriding member function print return varchar2 as
begin
return(/*super() ||*/ 'PART_TIME_STUDENT: { numhrs = ' ||
numhrs || ' }');
end;
end;
show errors
create table persons of person;
insert into persons values (person('name', 'address'));
insert into persons values (student('name', 'address', 10));
insert into persons values (part_time_student('name', 'address',
10, 15));
select p.print()
from persons p;
In the PRINT method I would like to reuse the inherited method
by calling it and let it do it's work without me having to copy
the code to the overridden method. In other words, I would like
to be able to call it using SUPER() or something similar. But
SUPER isn't reckognized by the compiler so what should I use?
I've also tried to call the method directly, eg in
PART_TIME_STUDENT.PRINT call STUDENT.PRINT(SELF) but because the
dynamic dispatch is too dynamic this actually calls
PART_TIME_STUDENT.PRINT recursively -- endless loop :-(. I would
consider this as a bug because I tell the compiler exactly which
method I want to call, as opposed to O.PRINT where I invoke the
most specialized method on an object O.
How can this be done?
Thanks.
Finn Ellebaek Nielsen
ChangeGroup ApS

Dynamic dispatch VISA and net

Hi,
I am learning to use LVOOP. I want to have hardware abstraction layer (HAL) for my test program so it works for different instruments.
Most of the instruments are connected to the computer using GPIB so I can use VISA.Therefore, I created a hardware abstraction class called "meter" with a VISA as its property. So I have a dynamical dispatch VI called write VISA. This can work if all the child instruments are communicated with VISA.
However, one instrument is connected using USB and the vendor's instrument driver is .Net. So this one instrument won't work with dynamical dispatch because I can't using write VISA.
What is the best way to handle this situation?
Thanks,
Joseph
Solved!
Go to Solution.

This would be an idication of a poor OOP design. What would be a prefered design would be to define a base class which contains the common methods for the device family you are abstracting. Rather than having a generic write you are better off to define methods interms of functionality , such as set power. You could make these methods be pure virtual which means chilredn classes must provide an implementation for that method. With this design you cannot create an instance of your base class but would create the correct child instance which is specific to the particular meter you are using. Also, having a method called "writeVISA" implies th eimplementation. Which as you found out makes it difficult for your to create USB or TCP implementations. If you want to provide a generic write methos simply call it write. Again, force the child classes to provide an implementation pof the method and they will provide the correct code necessary to communicate with the device. it may uise VISA, the native TCP or can and string methods. It doesn['t really matter. It is up to the child class ro provide the specific implementation.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Static verse dynamic dispatch call

I'm just getting started with creating my own lab view classes using the class object but I'm having trouble with some of the basic concepts. Are there any good tutorials or knowledge base articles which talk about how to create and use LabVIEW classes? I'm getting hung on static verses dynamic dispatch calls specifically.
Any help would be appreciated!
Thank you,
Craig

I'm still getting a handle on LVOOP myself.
Those two different methods control which VI actually gets called when your app is running.
THe static method is very similar to calling a normal sub-VI in LV except you are passing LVOOP data.
The dynamic comes into play when you have more than one class and one is a child of the other. In that case you can create a VI for the child that has the same name as a VI in the parent, but because it has different data, the data it accepts and return is different. This OTHER VI in the child will under the right condition be called instead of the VI in the parent. I understand this to be concidered over-riding. Which versino will be called? It is dicated by the data you pass to the sub_VI call. If you pass the parent data, the parent versino will be called and vise versa.
So the VI to call is determined at run-time depending on the data.
I hope I got that right!
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Load class from XML (Dynamic Dispatch)

I'm continuing my voyage into the realms of LVOOP.....
I have encountered a new problem which I am sure there's a solution to.....
I have a certain hierarchy and I want to implement a single save and load routine for all objects int he hierarchy (located int he parent class of course).
Using the "flatten to XML" I'm able to create some nice XML files with all parent and sibling information saved (as long as the values are non-default of course).
Where I am running into problems is the loading of the data within this XML file. I want to be able to take an object and basically re-initialise it to the values within the file. All fine and good I thought, but it doesn't work.
The problem is that when using the VI with Dynamic dispatch inputs, the output of the "Unflatten from XML" is giving me a conflict with the Dynamic dispatch output saying the obejct types do not necessarily match. Is it not possible to match the object type on the input and output of the "Unflatten from XML" primitive?
If I try removing the "Dynamic Dispatch" input to a static input, then it only loads the data for the parent class regardless of the actual input class.
Am I doing something silly here or is there no other way to properly load a sibling class from a file using only a method residing within the parent class? I was hoping I could have a single "Save-Restore" function residing within my parent class to make life easier for me.
Shane.
Message Edited by Intaris on 06-17-2009 05:24 AM
Say hello to my little friend.
RFC 2323 FHE-Compliant

Hi Tst,
Problem is that in order for the cast to yield any useful results, I have to make the inputs and outputs non-Dynamic which results in ONLY the data for the parent class being loaded.
If the inputs and outputs are Dynamic, then a cast will not solve the problem (It could be a grandchild class being cast as a child, thus breaking the dynamic dispatch tables).
The only solution I see is for the "UnFlatten from XML" to RETAIN the true object type.
Either that or use my beautiful solution
Shane.
Ps I just did a bit of a test of the race condition probabilities. I ran 100000 tests (100k) with a program stressing both cores AND ram of my machine in parallel and all 100k of 100k iterations worked out OK. I suppose that lets me think I should be in the range of at least 99.99%.......
Say hello to my little friend.
RFC 2323 FHE-Compliant

Why can't a reentrant dynamic dispatch method preallocate clones?

Does anybody know why a reentrant dynamic dispatch method cannot preallocate clones? The VI breaks unless you set shared clones.
=====================
LabVIEW 2012
Solved!
Go to Solution.

nathand wrote:
A bit more information here: http://lavag.org/topic/10539-reentrant-vi-with-dynamic-input-terminal-must-use-share-clones-between-...
I have to admit. Steve Mercer explained it to me at a LUG (OK to the LUG) I'm still betting that this will eventaully be worked around by LabVIEW R&D. When the use cases make the investment worthwhile
Jeff

Is it possible to create a dynamic dispatch VI from parent VI as a template

Hi all,
I'm new to LVOOP and wondering if it's possible to create a dynamic dispatch VI from the parent VI as a template.
For example:
I've got a Class-method in the parent class. All child-classes use this method except of one child, which needs a little tweak on this VI.
So I need to overload the VI in the child class.
When I choose "New -> New Dynamic Dispatch VI" I get an VI based on a template
(As described by Darren Nattinger here: http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-07-07-2010/m-p/1172483/highlight/true#M510414 )
Is it possible to get a copy of the parent VI instead that I can tweak ?
Thanks you in advance!
Best regards,
Balze

An over-ride VI is not that special.
The input and output classe must be "Dynamic".
The icon connectors have to be the same.
The Over-ride VI must have the same name as the parent and be a member of the child class.
So Save-as add to project but not to class.
Move to child class.
Rename.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Dynamic Dispatch

Hello，everybody，
I am new to LVOOP,now I try to utilize LVOOP to current project, but it seems that I encouter a strange dynamic dispatch problem, I draft two demo vi called System_CAN_Demo1.vi and Node_CAN_Demo1.vi respectively, they should have the same implement behivour. I add a break point on the block program located " ..\CAN\Network management\Wake up line\Execute.vi", and it should be dynamic dispatched as the execute method has been overriden. but It appears System__CAN_Demo1.vi normal while Node_CAN_Demo,vi abnomal.
please check out the attachment code for details.
Attachments:
Dynamic Dispatch ---Debug.zip ‏375 KB

Your subclasses have two copies of the st variable, one in the superclass and one in the subclass itself.
By accessing it directly through a superclass reference, the "wrong" one is used.
In other words, don't do that. Your superclass already has the st variable, so there's no reason to declare it in the subclasses.
Also you should make the variables private and use getters/setters to access them.

Application builder and dynamic class VIs name collision

I'm, using LabView 8.6 and I'm trying to make executable file.
The application builder returns warning:
"LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts."
...and no executable is created.
I'm pretty sure the warning comes from the fact that I use dynamic class member VIs, that are by definition have to have same names in both parent and children.
The following link (http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/caveats_apps_dlls/) says " If you don't rename the files, Application Builder moves the files to different folders for you to avoid a filename collision.", but no folders are created.
Any help here?

Hi,
If you have a parent class and one or more child classes, during the build LV will create a folder for each class with a conflicting VI. The offending VIs will be dumped in their respective folders, resolving the conflict. For what it's worth, I've used dynamic dispatch VIs several times in executables in LV 8.6 without seeing the issue you're reporting.
My only advice would be to:
1) make sure that you haven't somehow put two VIs of the same name in the same class (not even sure that's possible).
2) make sure you aren't renaming a VI during the build and creating a conflict
JasonP - CLD

Copy multiple dispatch vi to new child class

Hi, I have just started with LVOOP and while I'm pretty sure I have a good understanding of the overall theme, there is one problem I foresee if I continue.
Situation:
BoardType is parent of classes CC2600 and CC1300. Currently the child classes are just empty place holders.
Almost all the methods in the child classes will be of dynamic dispatch type (currently only one).
From what I understand a dynamic dispatch must be available in all child classes plus parent class in order to work as intended.
Problem:
If I would go forward and implementing LVOOP this would require approx 30 dynamic dispatch vis for each class. I can right click but for just these two children that's 60 + 30 vis I must create manually. I would much prefer just to create a template once and then just basically drag and drop 30+ new vis for each new class that is created.
Is there a way I can define a set of template dispatch vis in the parent BoardType and have them added to all the child classes?
I tried the save as copy, but the problem is that I still have to replace the connector pane to represent the new owning class.
If it helps here's a very basic block diagram of what's going to happen, just after Reset.vi there will be a lot of other dynamic dispatch vis.
Thanks in advance.
Michael

From the OP it sounded like you were literally just copying from the parent.
What I tend to do is finish one child class and then save a copy to a new name and change the internal data (if required) and DD vis (if required).
I do agree though that these kinds of operations could be hugely simplified using helper programs. Give the link provided by others a try.
Shane.
Say hello to my little friend.
RFC 2323 FHE-Compliant

Double dynamic dispatch

Similar Messages

Maybe you are looking for