I've set up multiple hrtimers for a satellite I'm building as part of my research group. Ideally, I'd like the access to these timers in the user space, so I'm wondering if there's a way to have the hrtimer generate a signal that can be handled in user space. Is that possible?
Related
How can I detect when the mouse cursor leaves a GtkTreeView row associated with a GtkListStore model?
Note that the signal "cursor-changed" is not what I am looking for, as it gets emitted as if it is a mouse enter (mouseover) event and I need it to be triggered when the mouse has just left the row instead. However within "cursor-changed" signal and a call of gtk_tree_view_get_cursor() I can obtain "the latest mouseovered row" to know which row the mouse cursor has previously entered. So I at least need a way to detect when the mouse cursor leaves some row.
Mouseout events normally require widgets to consume a window on the underlying implementation (the Xserver normally sends them when you abandon one window, Windows has another means of signalling them) so in environments where widgets don't use a window (this is quite normal on environments that don't have enough support from the implementation), they must be simulated. Normally you'll have to check the widget class hierarchy up to the root to see the place where those such events are being emulated, and how, to get an idea on how to deal with them. Probably you'll have some registering process in the superclasses to allow for a callback to be called on behalf of such events.
I am writing a GTK2 widget that shows images of all open windows. These images will update in real time.
To do this, I will use the X11 Damage extension. As far as I understand, the first step is to register an interest in damage events for a given window, like this:
damage = XDamageCreate (dpy, xid, XDamageReportNonEmpty);
How can I connect a signal handler to an X11 damage event? I will also need to pass the widget's structure into this callback function.
It is important that the execution of the rest of my GTK program is not halted while waiting for the events.
Update:
On further research, it would seem that I can respond to X11 events using gdk_window_add_filter. It seems to respond to many events, but it does not seem to respond to damage events. How can I make it respond to damage events?
Also, how can I prevent the callback function from causing an infinite loop when it updates the images?
As mentioned in the question , I was wondering whether it is possible for the controller to detect two button press simultaneously.
I am new to controller programming and started with the basics - blinking LED, then moved to buttons and now trying to play around button presses. I wanted to set some flag when both buttons are pressed together .
But as of I know, Only one ISR will be called in this case, thus detecting a single press. How can we achieve this...
(In some electronic devices, it has a specific functionality when we press certain buttons together e.g. resetting a phone when one presses 3 appropriate buttons simultaneously)
regards,
Messi
One single ISR triggered is not sufficient to detect a single button press. Because of the electro-mechanical signal bounce you get from all buttons, you need some kind of de-bouncing algorithm.
Furthermore, you need the program to be immune to EMI so that multiple interrupts won't create havoc on the stack whenever there are lots of pulses coming from the button(s).
For example:
If the buttons are connected to different ports that give different interrupts, create one interrupt per button. If they are connected to the same port, they can usually trigger the same interrupt (depending on MCU).
Whenever you get an interrupt as result of any signal edge (raising or falling) from the button, then in the ISR disable the interrupt and start a hardware timer of typically 5-10ms depending on the button. The timer should preferably trigger a timer interrupt.
Disabling the interrupt is necessary to filter out spurious interrupts caused by the bouncing and by potential EMI glitches.
The timer is necessary for the de-bouncing. If you cannot find the exact signal bounce time in the button data sheet (you most often don't), then simply measure it using an oscilloscope.
When the timer elapses, read the port and store the result in a variable. Enable the button interrupt once again.
The variable needs to be declared at file scope as static volatile. Static for private encapsulation, which is needed for good program design. Volatile to prevent against common compiler optimizer bugs, where the compiler doesn't realize that a variable has been modified by an ISR.
Implement the same for the first button. You'll have two different variables telling the current state of the buttons. Simply compare these two variables with each other to tell whether or not two buttons are pressed at the same time.
I wish to run a thread to update the Image in the picturebox . The image is streamed form the camera.
I require to stream images to two pictureboxes in two different forms, but one at a time.
Is it possible to create a single thread which can be accessed by both forms.
I think a backgroundworker would be appropriate. But how do I update the images in the picturebox of the respective forms?
I am using VC++ CLI/CLR
A Thread is an object which represent an independent path of execution (often run in parallel to another). I'm not really sure what you mean by "calling" a Thread but you can instantiate separate threads and run methods on them. Then between the Threads you have created you can use some kind of synchronisation such as Monitors, Mutexes and Events and a shared resource (being careful with cross-thread access).
For your problem I would be more tempted to use some kind of subscription pattern where the class which receives the images from the camera can update any observers of the camera. You may want an interface called ICameraObeserver with a method such as ReceiveImage, then any class could register with your camera class via some kind of method:
public void Register(ICameraObserver ico)
Then when the camera receives a new image, it can iterate through any subscribers of type ICameraObserver and call ReceiveImage passing the image it just received.
Just an idea. Be careful with updating the UI if you have multiple threads running - there is lots of information on this.
What I think you wanna do is this: when creating the new form, send to the constructer the first form as an object , then , and make a setter/ getter or just make the thread public, then you can "access" it from both forms as you requested.
Apologies for the rather verbose and long-winded post, but this problem's been perplexing me for a few weeks now so I'm posting as much information as I can in order to get this resolved quickly.
We have a WPF UserControl which is being loaded by a 3rd party app. The 3rd party app is a presentation application which loads and unloads controls on a schedule defined by an XML file which is downloaded from a server.
Our control, when it is loaded into the application makes a web request to a web service and uses the data from the response to display some information. We're using an MVVM architecture for the control. The entry point of the control is a method that is implementing an interface exposed by the main app and this is where the control's configuration is set up. This is also where I set the DataContext of our control to our MainViewModel.
The MainViewModel has two other view models as properties and the main UserControl has two child controls. Depending on the data received from the web service, the main UserControl decides which child control to display, e.g. if there is a HTTP error or the data received is not valid, then display child control A, otherwise display child control B. As you'd expect, these two child controls bind two separate view models each of which is a property of MainViewModel.
Now child control B (which is displayed when the data is valid) has a RefreshService property/field. RefreshService is an object that is responsible for updating the model in a number of ways and contains 4 System.Timers.Timers;
a _modelRefreshTimer
a _viewRefreshTimer
a _pageSwitchTimer
a _retryFeedRetrievalOnErrorTimer (this is only enabled when something goes wrong with retrieving data).
I should mention at this point that there are two types of data; the first changes every minute, the second changes every few hours. The controls' configuration decides which type we are using/displaying.
If data is of the first type then we update the model quite frequently (every 30 seconds) using the _modelRefreshTimer's events.
If the data is of the second type then we update the model after a longer interval. However, the view still needs to be refreshed every 30 seconds as stale data needs to be removed from the view (hence the _viewRefreshTimer).
The control also paginates the data so we can see more than we can fit on the display area. This works by breaking the data up into Lists and switching the CurrentPage (which is a List) property of the view model to the right List. This is done by handling the _pageSwitchTimer's Elapsed event.
Now the problem
My problem is that the control, when removed from the visual tree doesn't dispose of it's timers. This was first noticed when we started getting an unusually high number of requests on the web server end very soon after deploying this control and found that requests were being made at least once a second! We found that the timers were living on and not stopping hours after the control had been removed from view and that the more timers there were the more requests piled up at the web server.
My first solution was to implement IDisposable for the RefreshService and do some clean up when the control's UnLoaded event was fired. Within the RefreshServices Dispose method I've set Enabled to false for all the timers, then used the Stop() method on all of them. I've then called Dispose() too and set them to null. None of this worked.
After some reading around I found that event handlers may hold references to Timers and prevent them from being disposed and collected. After some more reading and researching I found that the best way around this was to use the Weak Event Pattern. Using this blog and this blog I've managed to work around the shortcomings in the Weak Event pattern.
However, none of this solves the problem. Timers are still not being disabled or stopped (let alone disposed) and web requests are continuing to build up. Mem Profiler tells me that "This type has N instances that are directly rooted by a delegate. This can indicate the delegate has not been properly removed" (where N is the number of instances). As far as I can tell though, all listeners of the Elapsed event for the timers are being removed during the cleanup so I can't understand why the timers continue to run.
Thanks for reading. Eagerly awaiting your suggestions/comments/solutions (if you got this far :-p)
have you tried using the DispatchTimer instead of System.Timers.Timer?
If a Timer is used in a WPF application, it is worth noting that the Timer runs on a different thread then the user interface (UI) thread. In order to access objects on the user interface (UI) thread, it is necessary to post the operation onto the Dispatcher of the user interface (UI) thread using Invoke or BeginInvoke. Reasons for using a DispatcherTimer opposed to a Timer are that the DispatcherTimer runs on the same thread as the Dispatcher and a DispatcherPriority can be set. ( from this blog )
It sounds to me like the timer signals are being queued faster than they are processed. For example, this would happen if each elapse event takes 2 seconds to process while the timer elapses every second. This would result in a backlog of "raise Elapse event now" signals being scheduled on the .NET thread pool.
Such a backlog would then continue to cause elapse events even after you stop the timer. From the System.Timers.Timer documentation:
Even if SynchronizingObject is true,
Elapsed events can occur after the
Dispose or Stop method has been called
or after the Enabled() property has
been set to false, because the signal
to raise the Elapsed event is always
queued for execution on a thread pool
thread. One way to resolve this race
condition is to set a flag that tells
the event handler for the Elapsed
event to ignore subsequent events.
To avoid a backlog of unprocessed timer signals building up in the thread pool, you can set AutoReset to false. That way the timer disables itself at each elapse. You can then set Enabled back to true after handling the elapse event. That way no additional elapse events will be scheduled until the last one has been handled.
Call timer.Elapsed -= new ElapsedEventHandler(); when your control is disposed of to manually detach the handler.