network communication in x control

[GregFreeman]

Id like to create an x control that is purely for reading and displaying udp messages. This way I can drop this in different apps and have the communication included, without having to recreate a parallel udp loop which passes data to the x control every time I want to use it. Is this ok to do or a major no no? My gut tells me this is a bad idea so it probably is, but I can't think of a good way to lump it all together.

[SteveChandler]

I can't think of why this would be bad. In fact I think it is a cool idea!

[GregFreeman]

Unfortunately it doesnt handle it well due to the timeout case not executing regularly. I'm thinking some kind of subpanel x control combination may due the trick but well see

[PiDi]

Well, let me think...

1. x-controls are made to extend GUI functionality. Implementing network communication inside x-control is the same (or worse) as implementing parallel loops communication using local variables. You can do it, yes, but you shouldn't.
2. x-control facade logic is fired in response to user actions on GUI (they are "event-driven"), and should end immediately after this action has been handled. You cannot just drop parallel loop into x-control and let it run its way, this would lock the whole VI using your x-control. So, you would need some logic to actually start another thread (loop) which would be run in different VI (i.e. use asynchronous dynamic call); and then you would still have some means to communicate with this thread... And STILL would have to "simulate" action on x-control to update the data showed in it (if you don't want user to click some "update" button all the time)

These are two issues that crossed my mind immediately after reading your post. I might have not understood your idea perfectly, but my first argument is pretty solid no matter what is your actual intention - x-controls are just GUI elements, not a part of program logic.

[GregFreeman]

---

@PiDi wrote:

Well, let me think...

---

These are the two main reasons I thought it may not work, but I tried for it anyways 

[Intaris]

---

1. x-controls are made to extend GUI functionality. Implementing network communication inside x-control is the same (or worse) as implementing parallel loops communication using local variables. You can do it, yes, but you shouldn't.
2. x-control facade logic is fired in response to user actions on GUI (they are "event-driven"), and should end immediately after this action has been handled. You cannot just drop parallel loop into x-control and let it run its way, this would lock the whole VI using your x-control. So, you would need some logic to actually start another thread (loop) which would be run in different VI (i.e. use asynchronous dynamic call); and then you would still have some means to communicate with this thread... And STILL would have to "simulate" action on x-control to update the data showed in it (if you don't want user to click some "update" button all the time)

---

These points are correct but by no mean that it shouldn't be done.  On the contrary, I think it's a good idea provided it's implemented properly.

Shane.

[SteveChandler]

---

@Intaris wrote:

These points are correct but by no mean that it shouldn't be done.  On the contrary, I think it's a good idea provided it's implemented properly.

Shane.

---

Precicely what I was thinking. I think that this can be done without locking up the GUI. But this is coming from a guy who has never written an x control and only has a general idea of what they are.

[altenbach]

I agree with the "no" crowd here.

---

@for(imstuck) wrote:
Id like to create an x control that is purely for reading and displaying udp messages. This way I can drop this in different apps and have the communication included...

---

You haven't really specified what you mean by "network communication". What is the direction?

1. It could be understood to act as a server, listening for incoming messages, then displaying them.
2. It also could be understood to act as a client, connecting to an external service, waiting for a response, then displaying it.
3. It could be understood as involving two-way ommunications.

Only #2 is potentially doable. For example it could (on demand) display some information from a weather service, etc. Since x-controls don't poll, the dsplayed information will be potentially stale until the user operates the x-control once more. So what's the point???

(#1 and #3 will not work, because to act as a server it would need to listen on a well-known port and you will get a conflict once you drop the second instance, because the port is already in use. You would need to listen forever, which would prevent the x-control from completing, stalling the entire code)

X-controls are special. They react even if the VI is in edit mode. (silly example).

Maybe I am completely misunderstanding what you want to do. So please clarify. 🙂

[SteveChandler]

I understood this to mean #2 with no user interaction. That is what I thought would be cool. Drop an indicator and get weather updates even in edit mode

[GregFreeman]

So I think I have an idea but more to come on how it works out once I get some free time 😉