Why don't Message Send methods have an output terminal for the send queue?

[onnodb]

A small question: I've been using the Message Maker tool to generate my Message classes. The "Send" methods it generates, only include an input terminal for the "send queue". If you want to send multiple messages in a row, it'd be easier if you could 'daisy chain' multiple Send methods. Is there a reason for not having a "send queue duplicate" output terminal?

For now, I'll add one myself in my version of the Message Maker, but I was just wondering if there's a reason for this, or if this could be a feature suggestion

Thanks!

[AristosQueue (NI)]

You know, I honestly can't think of a reason why we did that. Chemical deficiency between the ears? 🙂

And why hasn't this bitten me during development of various apps?

[onnodb]

Ah, OK, the whole framework is so well thought-out, I just assumed I was missing something

While we're in feature request mode: the Message Maker doesn't work too well if your project is using auto-populating folders — you tend to get lots of errors about VIs "already part of the project". Nothing too big (again, I fixed it on my own computer), but if there's a list of stuff somewhere that this would still fit in...?

Thanks again

[AristosQueue (NI)]

> the Message Maker doesn't work too well if your project is using auto-populating folders

There's a joke that starts, "Doctor, it hurts when I do this..." that I think is applicable here. 🙂

I will file the bug report (aka CAR) to address this, but I regularly advise anyone working with libraries (which includes classes) not to use autopopulating folders. They have a number of perfectly explainable but bizzare behaviors when interacting with the other features of a project. The project tree reflects logical relationships. The autopopulating folder reflects physical relationships. When these are not the same, weirdness results. I don't use that feature, myself, ever. People who do not work with libraries love it, so I think it has a place in LabVIEW, but the two features do not play well together.

Keep the ideas and bug reports coming. We want the Actor Framework to be as useful as possible for all our users.

[onnodb]

Thanks, AQ.

I'll think about your auto-populating folders comments. I've considered to stop using it in my projects before, but it just seems to make a lot of sense to have the folder structure on disk be the same as that in the Project Explorer — and once you've decided that, it seems cumbersome to keep them in sync manually.

[AristosQueue (NI)]

> and once you've decided that, it seems cumbersome to keep them in sync manually.

Oh, trust me, I agree with you there. I just don't think Autopopulating folders are the right solution. For me, they introduce more problems than they solve because I can never quite trust that they're doing the right thing once libraries get involved. Also, just because I move something in a virtual folder doesn't mean I want to blow away my source code control right then and there -- I might change my mind and move it back during development. I want to commit actual directory changes very rarely, generally near the ends of a development cycle. For that, though, I need different tools than autopopulate.