04-30-2014 11:05 AM
Karsten: That's exactly Boxshall's original idea; fails because it looks like part of the Task class.
04-30-2014 11:36 AM
This is a pretty timely discussion, as I am working on some updates to the AF Project Provider. I was going to look at including Karsten's code because it addresses this pain point and has the significant advantage of being working code. But if people would prefer something like Stephen's suggestion, we can do that instead, though it might take a bit longer since that would have to be coded.
What says the community?
04-30-2014 02:09 PM
Using Karsten's example, could you script just changing the background color of the original header or would that be more difficult than growing the header? Maybe even make the header black-and white if that is easier?
-Carl Wecker
04-30-2014 02:25 PM
Or add some kind of glyph to the original class header (like an envelope)
04-30-2014 02:36 PM
maxwellb wrote:
Or add some kind of glyph to the original class header (like an envelope)
Under that solution, if you create two messages for two methods of the same class, they both end up looking identical, as if they're members of the same class.
The following is my opinion. If the community decides another solution is better, I'm not going to use any executive veto on this one. But left to myself, these are the only solutions I consider viable:
a) leaving header blank so the user can fill it in
b) creating a header that is pure text by somehow squeezing the text "<method name> msg" into small space
c) creating a new header that is the combo of the original class header and the original method body.
04-30-2014 04:38 PM
Messages for two methods of the same class would only look identical if the two methods also have identical body icons. Which does not seem like a good thing to begin with.
Problem with my original code is that it will generate identical icons for two method that have the same body icon but are part of different classes (with different headers).
I can see the arguments to give the message classes unique headers. On the other hand in most cases the only reason they exist is to call the original method for that class. When looking at the icons The badge/ glyph would indicate that your dealing with the message class or it's sent method the rest of the icon would clearly identify the actor and it's method being called.
04-30-2014 04:41 PM
You know what I really would want? A halo on the Send.vi not unlike the Call By Reference node halo. And then the Do.vi could be whatever we want since it is rarely seen.
05-01-2014 03:28 AM
AristosQueue wrote:
You know what I really would want? A halo on the Send.vi not unlike the Call By Reference node halo. And then the Do.vi could be whatever we want since it is rarely seen.
Yes That would be ideal!. I feel the badge/glyph solution would get the closest to this.
05-03-2014 09:04 PM
This is how I handle the message icon, just cut off a corner. But I think adding a hola will be better.
05-05-2014 07:11 AM
AristosQueue wrote:
You know what I really would want? A halo on the Send.vi not unlike the Call By Reference node halo. And then the Do.vi could be whatever we want since it is rarely seen.
Beter yet would have it function like Call by Reference; drag and drop in the VI you want to call inside the Actor and wire up the inputs (actor and error inputs would be greyed out). Job done. Any message class needed would be autogenerated and never seen at all.