Multiple c# SerialPorts seems to hang my application - windows

I've an application in Windows forms that connects to 16 serialports. The structure I used for each one is:
private void Serial_CodeNip_15_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
string S = Serial_CodeNip_15.ReadExisting();
myProcess(S);
}
public delegate void del_myProcess(string stringa);
private void myProcess(string stringa)
{
if (this.InvokeRequired)
{
del_myProcess tmp = new del_myProcess(myProcess);
try
{
this.Invoke(tmp, stringa);
}
catch (Exception)
{
}
}
else
{
// my code here
}
}
Receiving data from barcode readers, works fine until more Readers (up 6 or 7) start reading at the same time. In this cases my application tends to hang and all readers denotes a difficult to catch data from serial input buffers. Is this the correct way to read async data from serialports or there’s another simple way to do that. I noticed that working with few serialports there’s no problem.
Thank you in advance for helping

Related

How to Poll For Controller Input In UWP App

I'm unsure about the best practice for obtaining and updating input received from a controller monitored using the GamePad class in UWP.
I've seen a couple of examples of people using Dispatch Timers and async loops inside the GamePadAdded event. In Win32 applications, I would have handled input in the WinMain update/message loop, but in UWP apps I don't know of anything similar.
Is there a loop in UWP apps that input should be collected/handled like in Win32 apps? What is the recommended protocol for polling for input from a input device (nominally a Xbox One controller)?
I'm happy to read more about UWP app development but I'm unsure of any guides that reference something like this.
Edit: It would be productive if, instead of downvoting and moving on, you shared thoughts on why this question deserved a downvote.
I've seen a couple of examples of people using Dispatch Timers and async loops inside the GamePadAdded event
This is the right way in UWP app to read Gamepad data. A little suggestion is, move the loop reading part on UI thread if you need to update UI frequently. See the solution in this blog
Is there a loop in UWP apps that input should be collected/handled like in Win32 apps
You may make a wrapper with custom event, see the open source implementation: XBoxGamepad
public class XBoxGamepad
{
private List<Gamepad> _controllers = new List<Gamepad>();
private bool _running = true;
Task backgroundWorkTask;
public event EventHandler<GamepadButtons> OnXBoxGamepadButtonPressA;
//omitted......
public XBoxGamepad()
{
Gamepad.GamepadAdded += Gamepad_GamepadAdded;
Gamepad.GamepadRemoved += Gamepad_GamepadRemoved;
backgroundWorkTask = Task.Run(() => PollGamepad());
}
//omitted......
private void Start()
{
_running = true;
}
public void Stop()
{
_running = false;
}
public async Task PollGamepad()
{
while (true)
{
if (_running)
{
foreach (Gamepad controller in _controllers)
{
if (controller.GetCurrentReading().Buttons == GamepadButtons.A)
{
OnXBoxGamepadButtonPressA(controller, controller.GetCurrentReading().Buttons);
}
//omitted......
}
}
await Task.Delay(50);
}
}
private void Gamepad_GamepadRemoved(object sender, Gamepad e)
{
_controllers.Remove(e);
}
private void Gamepad_GamepadAdded(object sender, Gamepad e)
{
_controllers.Add(e);
}
}

Windows Forms Event before the Closing event? [duplicate]

I have a form that spawns a BackgroundWorker, that should update form's own textbox (on main thread), hence Invoke((Action) (...)); call.
If in HandleClosingEvent I just do bgWorker.CancelAsync() then I get ObjectDisposedException on Invoke(...) call, understandably. But if I sit in HandleClosingEvent and wait for bgWorker to be done, than .Invoke(...) never returns, also understandably.
Any ideas how do I close this app without getting the exception, or the deadlock?
Following are 3 relevant methods of the simple Form1 class:
public Form1() {
InitializeComponent();
Closing += HandleClosingEvent;
this.bgWorker.RunWorkerAsync();
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e) {
while (!this.bgWorker.CancellationPending) {
Invoke((Action) (() => { this.textBox1.Text = Environment.TickCount.ToString(); }));
}
}
private void HandleClosingEvent(object sender, CancelEventArgs e) {
this.bgWorker.CancelAsync();
/////// while (this.bgWorker.CancellationPending) {} // deadlock
}
The only deadlock-safe and exception-safe way to do this that I know is to actually cancel the FormClosing event. Set e.Cancel = true if the BGW is still running and set a flag to indicate that the user requested a close. Then check that flag in the BGW's RunWorkerCompleted event handler and call Close() if it is set.
private bool closePending;
protected override void OnFormClosing(FormClosingEventArgs e) {
if (backgroundWorker1.IsBusy) {
closePending = true;
backgroundWorker1.CancelAsync();
e.Cancel = true;
this.Enabled = false; // or this.Hide()
return;
}
base.OnFormClosing(e);
}
void backgroundWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) {
if (closePending) this.Close();
closePending = false;
// etc...
}
I've found another way. If you have more backgroundWorkers you can make:
List<Thread> bgWorkersThreads = new List<Thread>();
and in every backgroundWorker's DoWork method make:
bgWorkesThreads.Add(Thread.CurrentThread);
Arter that you can use:
foreach (Thread thread in this.bgWorkersThreads)
{
thread.Abort();
}
I used this in Word Add-in in Control, which i use in CustomTaskPane. If someone close the document or application earlier then all my backgroundWorkes finishes their work, it raises some COM Exception(I don't remember exatly which).CancelAsync() doesn't work.
But with this, I can close all threads which are used by backgroundworkers Immediately in DocumentBeforeClose event and my problem is solved.
Here was my solution (Sorry it's in VB.Net).
When I run the FormClosing event I run BackgroundWorker1.CancelAsync() to set the CancellationPending value to True. Unfortunately, the program never really gets a chance to check the value CancellationPending value to set e.Cancel to true (which as far as I can tell, can only be done in BackgroundWorker1_DoWork).
I didn't remove that line, although it doesn't really seem to make a difference.
I added a line that would set my global variable, bClosingForm, to True. Then I added a line of code in my BackgroundWorker_WorkCompleted to check both e.Cancelled as well as the global variable, bClosingForm, before performing any ending steps.
Using this template, you should be able to close your form out at any time even if the backgroundworker is in the middle of something (which might not be good, but it's bound to happen so it might as well be dealt with). I'm not sure if it's necessary, but you could dispose the Background worker entirely in the Form_Closed event after this all takes place.
Private bClosingForm As Boolean = False
Private Sub SomeFormName_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
bClosingForm = True
BackgroundWorker1.CancelAsync()
End Sub
Private Sub backgroundWorker1_DoWork(ByVal sender As Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
'Run background tasks:
If BackgroundWorker1.CancellationPending Then
e.Cancel = True
Else
'Background work here
End If
End Sub
Private Sub BackgroundWorker1_RunWorkerCompleted(ByVal sender As System.Object, ByVal e As System.ComponentModel.RunWorkerCompletedEventArgs) Handles BackgroundWorker1.RunWorkerCompleted
If Not bClosingForm Then
If Not e.Cancelled Then
'Completion Work here
End If
End If
End Sub
Can you not wait on the signal in the destructor of the form?
AutoResetEvent workerDone = new AutoResetEvent();
private void HandleClosingEvent(object sender, CancelEventArgs e)
{
this.bgWorker.CancelAsync();
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
while (!this.bgWorker.CancellationPending) {
Invoke((Action) (() => { this.textBox1.Text =
Environment.TickCount.ToString(); }));
}
}
private ~Form1()
{
workerDone.WaitOne();
}
void backgroundWorker1_RunWorkerCompleted( Object sender, RunWorkerCompletedEventArgs e )
{
workerDone.Set();
}
Firstly, the ObjectDisposedException is only one possible pitfall here. Running the OP's code has produced the following InvalidOperationException on a substantial number of occasions:
Invoke or BeginInvoke cannot be called
on a control until the window handle
has been created.
I suppose this could be amended by starting the worker on the 'Loaded' callback rather than the constructor, but this entire ordeal can be avoided altogether if BackgroundWorker's Progress reporting mechanism is used. The following works well:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
while (!this.bgWorker.CancellationPending)
{
this.bgWorker.ReportProgress(Environment.TickCount);
Thread.Sleep(1);
}
}
private void bgWorker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
this.textBox1.Text = e.ProgressPercentage.ToString();
}
I kind of hijacked the percentage parameter but one can use the other overload to pass any parameter.
It is interesting to note that removing the above sleep call clogs the UI, consumes high CPU and continually increases the memory use. I guess it has something to do with the message queue of the GUI being overloaded. However, with the sleep call intact, the CPU usage is virtually 0 and the memory usage seems fine, too. To be prudent, perhaps a higher value than 1 ms should be used? An expert opinion here would be appreciated... Update: It appears that as long as the update isn't too frequent, it should be OK: Link
In any case, I can't foresee a scenario where the updating of the GUI has to be in intervals shorter than a couple of milliseconds (at least, in scenarios where a human is watching the GUI), so I think most of the time progress reporting would be the right choice
I really dont see why DoEvents is regarded as such a bad choice in this case if you are using this.enabled = false. I think it would make it quite neat.
protected override void OnFormClosing(FormClosingEventArgs e) {
this.Enabled = false; // or this.Hide()
e.Cancel = true;
backgroundWorker1.CancelAsync();
while (backgroundWorker1.IsBusy) {
Application.DoEvents();
}
e.cancel = false;
base.OnFormClosing(e);
}
Your backgroundworker should not use Invoke to update the textbox. It should ask the UI thread nicely to update the textbox using event ProgressChanged with the value to put in the textbox attached.
During event Closed (or maybe event Closing), the UI thread remembers that the form is closed before it cancels the backgroundworker.
Upon receiving the progressChanged the UI thread checks if the form is closed and only if not, it updates the textbox.
This won't work for everyone, but if you are doing something in a BackgroundWorker periodically, like every second or every 10 seconds, (perhaps polling a server) this seems to work well to stop the process in an orderly manner and without error messages (at least so far) and is easy to follow;
public void StopPoll()
{
MyBackgroundWorker.CancelAsync(); //Cancel background worker
AutoResetEvent1.Set(); //Release delay so cancellation occurs soon
}
private void bw_DoWork(object sender, DoWorkEventArgs e)
{
while (!MyBackgroundWorker.CancellationPending)
{
//Do some background stuff
MyBackgroundWorker.ReportProgress(0, (object)SomeData);
AutoResetEvent1.WaitOne(10000);
}
}
I'd pass in the SynchronizationContext associated with the textbox to the BackgroundWorker and use that to perform Updates on the UI thread. Using SynchronizationContext.Post, you can check if the control is disposed or disposing.
What about Me.IsHandleCreated?
Private Sub BwDownload_RunWorkerCompleted(sender As Object, e As System.ComponentModel.RunWorkerCompletedEventArgs) Handles BwDownload.RunWorkerCompleted
If Me.IsHandleCreated Then
'Form is still open, so proceed
End If
End Sub
Another way:
if (backgroundWorker.IsBusy)
{
backgroundWorker.CancelAsync();
while (backgroundWorker.IsBusy)
{
Application.DoEvents();
}
}
One solution that works, but too complicated. The idea is to spawn the timer that will keep trying to close the form, and form will refuse to close until said bgWorker is dead.
private void HandleClosingEvent(object sender, CancelEventArgs e) {
if (!this.bgWorker.IsBusy) {
// bgWorker is dead, let Closing event proceed.
e.Cancel = false;
return;
}
if (!this.bgWorker.CancellationPending) {
// it is first call to Closing, cancel the bgWorker.
this.bgWorker.CancelAsync();
this.timer1.Enabled = true;
}
// either this is first attempt to close the form, or bgWorker isn't dead.
e.Cancel = true;
}
private void timer1_Tick(object sender, EventArgs e) {
Trace.WriteLine("Trying to close...");
Close();
}

RadiusNetworks iBeacon didRangeBeaconsInRegion return 0 beacons

I am trying to detect iBeacons with a specific UUID and Major. The didRangeBeaconsInRegion is being called but the Beacon collection it returns has 0 entries.
The below is my code (abridged a bit)
private static final String BEACON_UUID = "F8AD3E82-0D91-4D9B-B5C7-7324744B2026";
private static final int BEACON_MAJOR = 36582;
#Override
public void onIBeaconServiceConnect() {
iBeaconManager.setRangeNotifier(new RangeNotifier() {
#Override
public void didRangeBeaconsInRegion(Collection<IBeacon> iBeacons, Region region) {
if (iBeacons.size() > 0) {
IBeacon thisBeacon = iBeacons.iterator().next();
}
}
});
try {
iBeaconManager.startRangingBeaconsInRegion(new Region("myUniqueID", BEACON_UUID, BEACON_MAJOR ,null));
} catch (RemoteException e) {
e.printStackTrace();
}
}
I am assuming I am doing my binding correctly as the didRangeBeaconsInRegion(..) is being called successfully.
I have used RadiusNetwork's own application to detected the beacons and that works fine and I can see them all so it is not seem to be an issue with Bluetooth on my device
A couple of tips:
Double check that your BEACON_UUID and BEACON_MAJOR are correct for the beacon that is transmitting. For testing, try setting both of these to null temporarily until you get it working, then you can set them back to the values you have.
It is normal for the iBeacons.size() to be zero sometimes if a beacon did not happen to be detected in a given cycle. But it should not always be of size zero. I'm not sure how you are testing, but try adding a Log.d(TAG, "Number of beacons detected: "+iBeacons.size()); and let it run to see if you ever get a non-zero number.
I suggest to check the uuid , major and minor values of your beacons and make them match with the region u want.
didRangeBeaconsInRegion should return an array af beacons.
You can use the "beecon" app to update easily the values.
Hope this can help you.
Regards.

WP7 How to write a function: binding data method will be called every 10s?

Could you show me the way or the idea how to execute biding data every 10s??
Let's see the code below:
private void PhoneApplicationPage_Loaded(object sender, RoutedEventArgs e)
{
proxy.DanhSachPhongChoiCompleted += new
EventHandler<DanhSachPhongChoiCompletedEventArgs>(proxy_DanhSachPhongChoiCompleted);
proxy.DanhSachPhongChoiAsync();
}
void proxy_DanhSachPhongChoiCompleted(object sender, DanhSachPhongChoiCompletedEventArgs e)
{
Room[] table = e.Result;
listDSPhong.ItemsSource = e.Result;
}
We can see: ater my page loaded, the binding data will execute ONLY ONE TIME. I need to call 2 methods below every 10s. How should I do? Thanks for teaching me!
proxy.DanhSachPhongChoiCompleted += new
EventHandler<DanhSachPhongChoiCompletedEventArgs>(proxy_DanhSachPhongChoiCompleted);
proxy.DanhSachPhongChoiAsync();
You can use e.g. DispatcherTimer class.
Here's the sample:
https://stackoverflow.com/a/3266071/126995
You better start your timer in NavigatedTo, and kill it in NavigatedFrom.
P.S. I suspect there's a memory leak in your code. Please read this.
you can use Microsoft's reactive library
http://msdn.microsoft.com/en-us/data/gg577609.aspx
and do something like this :
public void callfunction()
{
IScheduler scheduler = NewThreadScheduler.Default;
scheduler.Schedule(TimeSpan.FromSeconds(5), new Action<Action<TimeSpan>>(myRepeatingFunction));
}
private void myRepeatingFunction(Action<TimeSpan> action)
{
//process here
action(TimeSpan.FromSeconds(5)); // five second interval
}

Java ME out of memory

I'm making a Java ME application for Symbian S60 5th edition and I have problem with the memory. After some time of running the app I recieve the out of memory exception.
I'm getting images from Google Maps (by the integrated GPS in Nokia 5800) and showing them.
I have this implemented like this:
class MIDlet with method setForm()
class Data which has a thread that collects info about the coordinates, gets image from Google maps, creates new form, appends the image, and calls the method setForm(f) from the Midlet.
Probable the Display.setCurrent(Form f) keeps references on the forms and like this the memory gets fast full.
I tried with Canvas but it has some stupid UI (some circle and some 4 buttons) that I don't like.
How can I solve this problem?
PS: the code...
In class MIDlet
public void setInfo(Form f)
{
getDisplay().setCurrent(f);
}
in class TouristData which collects information about location and gets map image
private attributes:
private Form f=null;
private ImageItem imageItem=null;
private Image img = null;
method locationUpdated which is called when recieve new location:
public void locationUpdated(LocationProvider provider,final Location location)
{
if (!firstLocationUpdate)
{
firstLocationUpdate = true;
statusListener.firstLocationUpdateEvent();
}
if(touristUI != null)
{
new Thread()
{
public void run()
{
if(location != null && location.isValid())
{
//lokacija je, prikaži!
try
{
QualifiedCoordinates coord =location.getQualifiedCoordinates();
if(imageItem == null)
{
imageItem = new ImageItem(null,null,0,null);
imageItem.setAltText("ni povezave");
f.append(imageItem);
}
else
{
img = googleConnector.retrieveStaticImage2(360,470, coord.getLatitude(), coord.getLongitude(), 16, "png32"); //z markerje
imageItem.setImage(img);
}
}catch(Exception e)
{}
}
else
{
}
}
}.start();
}
}
Are you keeping references to the forms or the images? These will keep them from being garbage collected and will cause out of memory errors.
It is hard to tell without some source code. Anyway, it will be better to re-architect your Midlet not to create new forms, but to reuse the same one.

Resources