Hi everyone: I’m actually working on a quite complicated project in which I have to make various views communicate with each other: I am (or should I say I was? ) a very happy user of the “system.perspective.sendMessage” paradigm, but although I believe it is a very useful feature (and even vital when the view structure becomes complicated), I believe that the usage is becoming a bit unpractical, here are some points:
first of all, it seems to me that there is no way to know if a particular component implements some sort of event handler: it’s not a big deal for components like buttons, which are supposed to have at least an “onClick” script implemented, but what if I’m handling some event on the root, or on a container? A little icon on the right of the component that implements an event handler could help;
there is even no way to know if a component is implementing a message handler, or a custom method, see the notes above;
last but not least, there is no way to correlate a message handler to the component that is calling the related “sendMessage”. Ok, I can use the Find/replace window to search for a specific message (I must know first the message beeing sent or handled, but never mind this for now): unfortunately, it seems that from the new 8.0.3 release the find/replace feature doesn’t work anymore if searching through “all windows”.
Given that the Find / Replace problem is temporary and will surely be solved, what would I like to know is if new features will be developed that can lighten the points above? I’m probably asking too much, but I think it would be useful to have some kind of mechanism to highlight the components that manage a certain message, or maybe some sort of shortcut that allows me to easily navigate between the producer(s) and the consumer(s) of a given message. Is this just fantasy?
"all windows" will only search Vision Windows. Please try again while using "All Views".
While attempting to replicate the issue of being unable to locate Message Keys, I was able to locate all expected Message Keys in a nightly build from last week, so I'm going to assume for now that the failure to locate Message Keys can be attributed to your searching Windows instead of Views.
As for providing Icons for components in the Project Browser to determine whether or not they have an Event Handler or Message Handler implemented... I'm not exactly "against" the idea, but I would point out that the project browser is already getting a little "busy". For large projects with deeply nested components, Icons would only be visible if the Project browser was expanded wide enough to take up a large portion of the screen, when that's most likely not a desirable precondition to seeing icons. If you'd like to formally request the icons as a feature, you could always do so on the ideas forum.
First of all many thanks for replying. I apologize but I made a mistake, in fact I meant exactly "All Views" and not "All Windows": anyway, I've submitted a ticket on this point and we are working with the tech support to solve the problem, I will eventually post results here.
Thanks for the suggestion, I will think about posting it there. Anyway, mine one was not really a "feature suggestion": before starting to use perspective, I was used to see little icons near objects to show that something is happening (alarms/history/handlers on tags, the same on vision windows), and they're still there, so it seemed to me natural to follow the same pattern with perspective views
However, with my post I mainly wanted to emphasize that the messaging function is such a powerful feature that the lack of a tool to keep track of message endpoints is like a missing brick for the functionality itself, which makes it less attractive to use. I was hoping to get come kind of spoiler about the "completion" of this function
Icons (we call them badges) in the project browser in Perspective, similar to what Vision has on components/windows, are something we’re planning on implementing.
The idea of a master list of message handlers/receivers isn’t a bad one, but it somewhat goes back to a problem we’ve always had with Vision - because Ignition uses strings to reference things all over the place, it’s hard (basically impossible) to “look up” every possible place that’s sending a message. It would be possible to see all the message handlers on a screen, but every call to system.perspective.sendMessage could be constructing a message handler name dynamically, so we can’t really look up where all your message handlers are being fired.
Perhaps it would be nice to be able to select the icons that you want to display? That way you could include a whole bunch more and let the user decide what's important to them or not.
I supposed that tracking the "sendMessage" call could represent a problem: maybe I'm terribly wrong, but since the script code is already related to some particular component, don't you already have the opportunity to parse the script code searching for the "sendMessage" calls? in this way you could build up some internal collection that couples the message ids to the components that are calling them. Or maybe I misunderstood what you meant?
Thanks, but since it's a feature they already planned to implement, at this point I believe there's no need to suggest it again
Even this would not be 100%, because you can use sendMessage via the Scripting Library. We're tossing around several ideas internally, but it'll be some time before they're finalized and implemented.
Also, as Paul mentioned, we can't construct a list of messageKeys from scripting invocations, because
This is not a good assumption. We can plan and open tickets all day long, but if customers do not request such a feature, there is little chance it will be implemented, as everything we do is done in an attempt to fulfill a need in the product. If no one says they need a feature, why would we dedicate time to said feature, when we ARE getting requests for others?
Ok, I don't know the original code from which Ignition is built, so mine are only rather abstract hypotheses
Sure it complicates the situation, anyway I believe that limiting to the string literals messages could be a good compromise, as it is probably the most commonly used solution. The above code could also be refactored in something like this:
) a very happy user of the “system.perspective.sendMessage” paradigm, but although I believe it is a very useful feature (and even vital when the view structure becomes complicated), I believe that the usage is becoming a bit unpractical, here are some points:
