Jon,
You're fighting against the very structure of how RB deals with it sockets.
I suspect you will be better off rewriting that section of code to use a timer
to service the repeating activity instead of doing it inside a loop.
Put your loops actions in a timer's action handler. You'll have to pass in
parameters as properties and the timer's action method would do the job of
detecting the loop termination and stopping itself.
I recommend subclassing a timer so you can have the methods and the properties
nicely encapsulated
Add a "start" method that passes in the required parameters and start the timer
running.
That encapsulates the implementation and allows for the rest of your code to
read nicely.
You may also wish to add a killLoop method.
e.g,.
MethodPar1
do stuff before the loop
myLoop = new myLoopTimerClass
myLoop.start(param1, param2, param3)
(your method Part1 ends here. Continue actions that would be after the loop
by
having the timer end its work with a call to "methodPart2)
Methodpart2
do the stuff that was before your loop
This strategy has worked well for a few of our projects.
Another benefit is that design paradigm forces you to write your code in a more
asynchronous design. Synchronous loops are easier to conceive, but refactoring
into an asynchronous design lets your app behave more adaptively. With good
encapsulation of the timer implementation, the code still remains easy to
understand. One trick for readability is to have the loopTimer implement all
its work in methods that are defined in the object you originally had your
synchronous loop.
Change to a short period, repeating timer. You will no longer have the issue of
a loop halting service of the main app background services like the GUI and the
ports.
Guy Kuo
On Aug 24, 2012, at 2:55 PM, Jon Daggett <[email protected]> wrote:
> Christian (or anyone else with ideas),
>
> I am using TCP and UDP sockets within a loop. The UDP sockets don't go out
> properly unless I put either app.DoEvents (big no no I realize, so I don't
> want to do that), or I found that DelayMBS also solves the problem, however
> that adds too much delay.
>
> Christian had suggested using the poll function on the socket, and while that
> works great for TCP sockets, it appears to do nothing on UDP sockets (at
> least for transmit anyway).
>
> So, I'm back to the DelayMBS which works wonderfully, however even with the
> shortest value it is introducing too much delay.
>
> Is there another way of doing this? Either something like DelayMBS which has
> a much shorter delay, or a better method for getting the UDPsocket to send
> out the data when in the loop. I've tried a thread and that still doesn't do
> it, and also a timer calling the poll function and no luck with that either.
>
>
> Thanks in advance!
>
> Jon
>
>
> Jon Daggett
> Castle Studios Productions
> www.castlestudios.com
>
>
>
>
>
> _______________________________________________
> Mbsplugins_monkeybreadsoftware.info mailing list
> [email protected]
> https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
>
_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
[email protected]
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
