I am using numeric updowncontrol. For min and max values changed listening for these events
this.numDownMinLimit.ValueChanged += new System.EventHandler(this.numDownMinLimit_ValueChanged);
this.numDownMaxLimit.ValueChanged += new System.EventHandler(this.numDownMaxLimit_ValueChanged);
step size set is 0.1
The eventhandler takes some time to complete.
If you keep the mouse pressed for a period of time and then release it, the eventhandler still executes with the previous values which were fired.
How do we prevent this scenario from occurring? I would like to discard the remaining events which are still in the queue, waiting to be handled, when the user releases the mouse button.
You need to have a look at the NumericUpDownAcceleration Class which handles this behaviour:
From: http://msdn.microsoft.com/en-us/library/system.windows.forms.numericupdownacceleration.aspx
The NumericUpDownAcceleration object
is used by the NumericUpDown control
to optionally provide acceleration
when incrementing or decrementing the
control through a large quantity of
numbers.
Let us know how you get on.
Related
The "Assembler" should stop working for 2 hours after 10 assemblies are done.
How can I achieve that?
There are so many ways to do this depending on what it means to stop working and what the implications are for the incoming parts.. but here's one option
create a resourcePool called Machine, this will be used along with the technicians:
on the "on exit" action of the assembler do this (I use 9 instead of 10 because the out.count() doesn't count until the agent is completely out, so when it counts 9, it means that you have produced 10)
if(self.out.count()==9){
machine.set_capacity(0);
create_MyDynamicEvent(2, HOUR);
}
In your dynamice event (that you have to create) you will add the following code:
machine.set_capacity(1);
A second option is to have a variable countAssembler count the number of items produced... then
on exit you write countAssembler++;
on enter delay you write the following:
if(countAssembler==10){
self.suspend(agent);
create_MyDynamicEvent(2, HOUR,agent);
}
on the dynamic event you write:
assembler.resume(agent);
Don't forget to add the parameter needed in the dynamic event:
Create a variable called countAssembler of type int. Increment this as agents pass through the assembler. Also create a variable called assemblerStopTime. You also record the assembler stop time with assemblerStopTime=time()
Place a selectOutputOut block before the and let them in if countAssembler value is less than 10. Otherwise send to a Wait block.
Now, to maintain the FIFO rule, in the first selectOutputOut condition, you need to check also if there is any agent in the wait block and if the current time - assemblerStopTime is greater than 2. If there is, you free it and send to the assembler with wait.free(0) function. And send the current agent to wait. You also need to reset the countAssembler to zero.
I have flink stream and I am calucating few things on some time window say 30 seconds.
here what happens it is giving me result my aggregating previous windows as well.
say for first 30 seconds I get result 10.
next thiry seconds I want fresh result, instead I get last window result + new
and so on.
so my question is how I get fresh result for each window.
You need to use a purging trigger. What you want is FIRE_AND_PURGE (emit and remove window content), what the default flink trigger does is FIRE (emit and keep window content).
input
.keyBy(...)
.timeWindow(Time.seconds(30))
// The important part: Replace the default non-purging ProcessingTimeTrigger
.trigger(new PurgingTrigger[..., TimeWindow](ProcessingTimeTrigger))
.reduce(...)
For a more in depth explanation have a look into Triggers and FIRE vs FIRE_AND_PURGE.
A Trigger determines when a window (as formed by the window assigner) is ready to be processed by the window function. Each WindowAssigner comes with a default Trigger. If the default trigger does not fit your needs, you can specify a custom trigger using trigger(...).
When a trigger fires, it can either FIRE or FIRE_AND_PURGE. While FIRE keeps the contents of the window, FIRE_AND_PURGE removes its content. By default, the pre-implemented triggers simply FIRE without purging the window state.
The functionality you describe can be found in Tumbling Windows: https://ci.apache.org/projects/flink/flink-docs-release-1.2/dev/windows.html#tumbling-windows
A bit more detail and/or code would help :)
I'm little late into this question but I encountered the same issue with OP's. What I found out later was a bug in my own code. FYI my mistake could be good reference for your problem.
// Old code (modified to be an example):
val tenSecondGrouping: DataStream[MyCustomGrouping] = userIdsStream
.keyBy(_.somePartitionedKey)
.window(TumblingProcessingTimeWindows.of(Time.of(10, TimeUnit.SECONDS)))
.trigger(ProcessingTimeTrigger.create())
.aggregate(new MyCustomAggregateFunc(new MyCustomGrouping()))
Bug happened at new MyCustomGrouping: I unintentionally created a singleton MyCustomGrouping object and reusing it in MyCustomAggregateFunc. As more tumbling windows created, the later aggregation results grow crazy! The fix was to create new MyCustomGrouping each time MyCustomAggregateFunc is triggered. So:
// New code, problem solved
...
.aggregate(new MyCustomAggregateFunc(() => new MyCustomGrouping()))
// passing in a func to create new object per trigger
I am wondering what is the canonical approach to solve the following problem in Rx: Say I have two observables, mouse_down and mouse_up, whose elements represent mouse button presses. In a very simplistic scenario, if I wanted to detect a long press, I could do it the following way (in this case using RxPy, but conceptually the same in any Rx implementation):
mouse_long_press = mouse_down.delay(1000).take_until(mouse_up).repeat()
However, problems arise when we need to hoist some information from the mouse_down observable to the mouse_up observable. For example, consider if the elements of the observable stored information about which mouse button was pressed. Obviously, we would only want to pair mouse_down with mouse_up of the corresponding button. One solution that I came up with is this:
mouse_long_press = mouse_down.select_many(lambda x:
rx.Observable.just(x).delay(1000)\
.take_until(mouse_up.where(lambda y: x.button == y.button))
)
If there is a more straight forward solution, I would love to hear it - but as far as I can tell this works. However, things get more complicated, if we also want to detect how far the mouse has moved between mouse_down and mouse_up. For this we need to introduce a new observable mouse_move, which carries information about the mouse position.
mouse_long_press = mouse_down.select_many(lambda x:
mouse_move.select(lambda z: distance(x, z) > 100).delay(1000)\
.take_until(mouse_up.where(lambda y: x.button == y.button))
)
However, this is pretty much where I get stuck. Whenever a button is held down longer than 1 second, I get a bunch of boolean values. However, I only want to detect a long press when all of them are false, which sounds like the perfect case for the all operator. It feels like there's only a small step missing, but I haven't been able to figure out how to make it work so far. Perhaps I am also doing things in a backwards way. Looking forward to any suggestions.
Ok, I guess I found a possible answer. RxPy has a take_with_time operator, which works for this purpose. Not really as straight-forward as I was hoping for (not sure if the take_with_time is avaliable in other Rx implementations).
mouse_long_press = mouse_down.select_many(lambda x:
mouse_moves.take_with_time(1000).all(lambda z: distance(x, z) < 100)\
.take_until(mouse_up.where(lambda y: x.button == y.button))
)
I will leave the question open for now in case somebody has a better suggestion.
I'd approach the problem differently, by creating a stream of mouse presses with length information, and filtering that for presses longer than 1s.
First let's assume that you only have one mouse button. Merge the mouse_up and mouse_down streams and assign time intervals between them with the time_interval() operator. You will get a stream of intervals since previous event, along with the event itself. Assuming your mouse-ups and mouse-downs alternate, this means your events now are:
(down + time since last up), (up + time since last down), (down + time since last up) ...
Now, simply filter for x.value.type == "up" and x.interval > datetime.timedelta(seconds=1)
(You can also validate this with pairwise(), which always gives you the current + previous event, so you can check that the previous one is down and the current one is up.)
Second, add the mouse movement information, using the window() operator.
(This part is untested, I'm going off the docs of how it's supposed to behave, but the docs aren't very clear. So YMMV. )
The idea is that you can collect sequences of events from an observable, separated into groups based on another observable. From the docs:
The window_openings observable is going to be the merged up/down stream, or the interval stream, whichever is more convenient. Then you can flat_map() (or select_many, which is the same thing) the result and work out the distance in whichever way you like.
Again, you should end up with a stream of distances between up/down events. Then you can zip() this stream with the interval stream, at which point you can filter for up events and get both time and distance until the previous down.
Third, what if you are getting events for multiple mouse buttons?
Simply use group_by() operator to split into per-button streams and proceed as above.
Full code below:
Event = collections.NamedTuple("Event", "event interval distance")
def sum_distance(move_stream):
# put your distance calculation here; something like:
return move_stream.pairwise().reduce(lambda acc, (a, b): acc + distance(a, b), 0)
def mouse_press(updown_stream):
# shared stream for less duplication
shared = updown_stream.share()
intervals = shared.time_interval() # element is: (interval=timedelta, value=original event)
distances = mouse_move.window(shared).flat_map(sum_distance)
zipped = intervals.zip(distances, lambda i, d: \
Event(i.value, i.interval, d) )
mouse_long_press = (
# merge the mouse streams
rx.Observable.merge(mouse_up, mouse_down)
# separate into streams for each button
.group_by(lambda x: x.button)
# create per-button event streams per above and merge results back
.flat_map(mouse_press)
# filter by event type and length
.filter(lambda ev: ev.event.type == "up" and ev.interval >= datetime.timedelta(seconds=1)
)
I'm using libspotify SDK, C library for win32.
I think to have a right setup, every session callback is registered. I don't understand why i can't receive the call for end_of_track, while music_delivery continues to be called with zero padding 22050 long frames.
I attempt to start playing first loading the track with sp_session_load; till it returns SP_ERROR_IS_LOADING I post a message on my message queue (synchronization method I've used, PostMessage win32 API) in order to reload again with same API sp_session_load. As soon as it returns SP_ERROR_OK I use the sp_session_play and the music_delivery starts immediately, with correct frames.
I don't know why at the end of track the libspotify runtime then start sending zero padded frames, instead of calling end_of_track callback.
In other conditions it works perfectly: I've used the sp_track obtained from a album browse, so the track is fully loaded at the moment I load to the current session for playing: with this track, it works fine with end_of_track called correctly. In the case with padding error, I search the track using its Spotify URI and got the results; in this case the track metadata are not still ready (at the play attempt) so I used that kind of "polling" on sp_session_load with PostMessage.
Can anybody help me?
I ran into the same problem and I think the issue was that I was consuming the data too fast without giving other threads time to do any work since I was spending all of my time in the music_delivery callback. I found that if I add some throttling and notify the main thread that it can wake up to do some processing, the extra zeros at the end of track is reduced to one delivery of 22,050 frames (or 500ms at 44.1kHz).
Here is an example of what I added to my callback, heavily borrowed from the jukebox.c example provided with the SDK:
/* Buffer 1 second of data, then notify the main thread to do some processing */
if (g_throttle > format->sample_rate) {
pthread_mutex_lock(&g_notify_mutex);
g_notify_do = 1;
pthread_cond_signal(&g_notify_cond);
pthread_mutex_unlock(&g_notify_mutex);
// Reset the throttle counter
g_throttle = 0;
return 0;
}
As I said, there was still 22,050 frames of zeros delivered before the track stopped, but I believe libspotify may purposely do this to ensure that the duration calculated by the number of frames received (song_duration_ms = total_frames_delivered / sample_rate * 1000) is greater than or equal to the duration reported by sp_track_duration. In my case, the track I was trying to stream was 172,000ms in duration, without the extra padding the duration calculated is 171,796ms, but with the padding it was 172,296ms.
Hope this helps.
Guys help me to understand the timeouts usage. The documentation gives quite a couple of words about them:
popTimeout- Retrieves the previous timeout value from a stack, restores it as the current timeout value, and returns it.
pushTimeout - Stores the current timeout value on a stack and sets a new timeout value.
They also provide some code:
target = UIATarget.localTarget();
target.pushTimeout(2);
// attempt element access
target.popTimeout();
But I don't exactly understand how and when to use them. Can anybode give an example?
During automation testing, some elements might not become visible right away. so instruments uses a timeout (default 5 seconds) to wait for requested elements. They call this the grace period.
Sometimes the default grace period might not be what you need, so you can change the timeout to a shorter or longer value.
Using the pushTimeout and popTimeout makes sure that the previous grace period is restored after calling popTimeout, without the need to remember the previous grace period.
For example: in one of my tests, I don't want to wait for a popover to become active, but I just want to know if there is a popover active, and dismiss it if there is:
target.pushTimeout(0.0);
if ( target.isDeviceiPad() && ! isNull( popOver= app.mainWindow().popover() ) )
{
UIALogger.logDebug(" dismiss popup by tapping somewhere");
popOver.dismiss();
target.delay(0.2);
}
target.popTimeout();
BTW, the isNull() is a custom function I made, but you probably understand what is going on.