I'm trying to play with Om (yes, I know om.next is coming, but it's not clear when it will be ready--and I think the basic idea will apply), but have run into a simple (or should be) problem.
I have a component with a select widget that populates from the "effects" member of my app-state, and a button to send that effect downstream (controlling LED strips):
(defn effect-view [data owner]
(reify
om/IInitState
(init-state [_]
{:selected-effect nil})
om/IRenderState
(render-state [this state]
(dom/div {}
(dom/select #js {:id "effect"
:value (:selected-effect state)
:onChange #(handle-change % owner state)}
(for [effect (:effects data)]
(dom/option {:react-key (:name effect)} (:name effect))))
(dom/button #js {:id "send-effect"
:onClick (fn [e]
(queue-command "effect" (:selected-effect state)))
:react-key "send-effect"}
(str "Send Effect"))))))
Good so far actually; this mostly works. When the app-state is populated with :effects (via a REST call), this does indeed fill in the options.
The problem is that pesky :selected-effect state member. It's initially nil, but once the select element is populated, the selector displays the first element. So if the user clicks the "Send Effect" button, rather than getting the first effect it sends "nil"--because the "option" children are being filled in correctly but the view state hasn't changed.
When I change the effect list in the global state, I'd like the value of the selector (:selected-effect) in the view to change to the first item in the list, if the current value isn't valid (in other words, it starts at nil and I populate with effects A, B, and C--it should change the selected value to "A"... if I then populate with effects A, C, and D, it should stay A, but if I populated with B, C, D, it should then switch to B, if that makes sense.
How do I do this?
Solved! By... reading the documentation closer. Sigh.
The IWillReceiveProps protocol is called before the next props (app state) is actually set. So the following sets the component state prior to rendering. With this code added before om/IRenderState the code seems to do what I desired:
om/IWillReceiveProps
(will-receive-props [this next-props]
(let [effect-names (map :name (:effects next-props))]
(if-not (contains? effect-names (om/get-state owner :selected-effect))
(om/set-state! owner :selected-effect (first effect-names)))))
God deal; I consider this closed and can get on with the project.
Related
No sure if there's a lot of act-r programmer on here, but I can't seem to find a forum/group for that anywhere so...
I'm writing a program which as a chunk defined as (and the goal below):
(chunk-type position position-x position-y)
(chunk-type goal state last-pos)
In a production, I'm fetching the position of a thing on screen from the visual-location and then I would need to create a position chunk and put that in my goal's last-pos slot. Here's the production rule:
(P attend-projectile
=goal>
ISA goal
state nil
=visual-location>
screen-x =pos-x
screen-y =pos-y
?visual>
state free
==>
+visual>
cmd move-attention
screen-pos =visual-location
=goal>
state attended
last-pos (position pos-x screen-x pos-y screen-y)
)
Or something like that. I've tried various syntaxe. The problem boils down to:
I need to instantiate a chunk within a production (the position chunk) based on values recovered in the lhs,
then assign that chunk to a goal's slot.
Somehow I can't seem to find an equivalent example in the doc...
EDIT:
I do need this to be a chunk, not just storing the x & y position. Eventually this chunk will be extended to include an ID (which will be obtained from the visual location, e.g. a different letter will be assigned to each moving object). I will be tracking those object through time. Because I'm tracking through time, another chunk (trajectory) will contain 3 position chunks (with their IDs).
Other productions will expect to find this chunk (trajectory, once I have 3 position chunks) and make decisions based on that.
Obviously the above is a snippet of the code. But the conceptual difficulty I have is manipulating (instantiating/creating however it's called in actr nomentalture) chunks at runtime, essentially.
Why do you need another chunk? You have the chunk in the visual-location buffer with that information so why not use it:
(P attend-projectile
=goal>
ISA goal
state nil
=visual-location>
?visual>
state free
==>
+visual>
cmd move-attention
screen-pos =visual-location
=goal>
state attended
last-pos =visual-location
)
Of course, that doesn't answer the question that was asked.
To create a new chunk, the proper way to do so is through a request to the imaginal buffer which would then require a following production to harvest the result and place it into the slot of the goal buffer's chunk. Assuming that the slots you want in the new chunk are from the position chunk-type you show, and that the values are from the similarly named slots of the chunk in the visual-location buffer, this would create the new chunk in the imaginal buffer:
(P attend-projectile
=goal>
ISA goal
state nil
=visual-location>
screen-x =pos-x
screen-y =pos-y
?visual>
state free
==>
+visual>
cmd move-attention
screen-pos =visual-location
=goal>
state attended
+imaginal>
position-x =pos-x
position-y =pos-y
)
We have multiple sessions i-e four sessions opened in USD. I need to close without clicking on 'X' on the session.
Can it be possible to have 4 buttons on the toolbar and by clicking the third button will close the third session in USD?
This should be possible provided that Microsoft's documentation is valid. Even if it is possible, it would be crude, limited, and difficult to implement/maintain without writing custom code. I highly recommend a "close current session" button that simply closes the foreground session. Through configuration however, here's how you could theoretically do what you're asking.
Create a Close button for each session, considering your max number of sessions, let's say 4. On start of a new session, a series of actions fires in an attempt to locate a Close button upon which to attach the session close command, based on logic like this:
Does Global Context variable Session1ID have data?
If not, place the new session ID in Session1ID.
Does Global Context variable Session2ID have data?
Is the new session ID already stored in Session1ID?
If not, place the new session ID in Session2ID.
Does Global Context variable Session3ID have data?
Is the new session ID already stored in Session1ID or Session2ID?
If not, place the new session ID in Session3ID.
Does Global Context variable Session4ID have data?
Is the new session ID already stored in Session1ID, Session2ID, or Session3ID?
If not, place the new session ID in Session4ID.
The buttons themselves could be made visible or enabled based on whether their Session ID is in Global Context.
On click of any of these buttons, let's say #3, the following would occur:
Close Session command using Session3ID
Nullify value of Session3ID, making it available for the next attempt to attach a session ID.
I foresee a few problems with this. You may encounter issues reading from and writing to Global Context variables while inside of a session. Furthermore, you may encounter issues with closing background sessions by their ID.
Further still, closing sessions out-of-sequence would cause new sessions to attach to buttons in a disorderly-looking fashion, creating a bad user experience. Let's say you need to start six sessions (A, B, C, D, E, and F). You have to close the two sessions in the middle (B and C) before starting the last two due to your limit of 4. With A on button 1 and D on button 4, you start sessions E and F which attach to buttons 2 and 3. Now your four buttons correspond to sessions A, E, F, and D, while the session tabs themselves are in the order that you opened them: A, D, E, F. This would be a bad user experience. (I don't believe that you can manipulate the order in which buttons appear using replacement parameters. Button Order is likely to be configuration integers only.)
Hopefully, this clarifies the elegance of a simpler solution: Create a "Close Current Session" button that is only enabled or visible while you have a session.
I'm working on a project where i have a window with a size of 4 days, with a step of 1 day
.timewindow(Time.days(4), Time.days(1))
and i have also a trigger
.trigger(new myTrigger)
onEventTime ---> Continue
onProccessingTime ---> Continue
clear ---> Purge
onElement---> (if element.isFinalTransaction) TriggerResult.FIRE_AND_PRUGE
isFinalTransaction is a boolean, when true it call FAP.
the mean question is how can i make it return true/false depending on if the element is the last in the window or not
is there any method that can tell us if the current element is the last one in the window?
is there any method that can tell us if the current window is done (before sliding) or not ?
From the abstract trigger class (https://github.com/apache/flink/blob/master//flink-streaming-java/src/main/java/org/apache/flink/streaming/api/windowing/triggers/Trigger.java)
The short answer is no. The method onElement is called for every element that gets added to the pane. When an element gets added it's impossible to know if it is the last element, because that information is not known until the next element comes (and we see if it was in this window or the next one).
However, one alternative would be to check if the element is sufficiently close to the end of the end of the window (because onElement has access to window e.g. if (timestamp > window.getEnd - delta) ...
However, I can not think of a use case in which I would recommend this. If you need access to the last element in the window, you should probably just use a WindowFunction and in the apply method get the last element of the input iterable (input.last).
I want to destory my previously shown frame when a certain event is triggered.
I can't find anything regarding this in the reference manual.
You don't need to -- just (send frame show #f) to hide it. When the value is no longer reachable, it will be garbage-collected.
I am programming an FPS (First Person Shooter) game using "Gtkmm" as a window manager and I would like to do the "mouse-look". Therefore, I have to "grab" the mouse pointer to redirect all the mouse motion events to my application window.
There seems to be three overloaded functions to do that job and I have chosen the simplest one for the beginning:
Gdk::GrabStatus Gdk::Window::pointer_grab(bool owner_events, Gdk::EventMask event_mask, guint32 timestamp)
I have tried to put this function to my application but I have had "bad results" so far - it doesn't do what I want it to, it behaves "differently" on "Windows" than on "Linux", etc...
So I will write down what I have done so far, but first, what is my target: "I want to have my application in a window and want to be able to do the mouse-look with a mouse even when I leave the window with the mouse pointer".
So let's get to the function parameters:
-->bool owner_events: when I set it to "true", I got events only when I was inside the window, but (worse) when I set it to "false", I didn't get any events - so I set it to true (the better option :-) )
-->Gdk::EventMask event_mask: there should be those events which I want to catch. For now, I am interested only in mouse motion events, so I put there only "Gdk::POINTER_MOTION_MASK"
-->guint32 timestamp: this I also don't understand but when I put there pure "0", the grab status was OK, thus "GRAB_SUCCESS" (when I tried to set it to 1, 2 or whatever other number, it returned "GRAB_INVALID_TIME" as a grab status) - so I set it to "0"
And now when I run it on Linux, it although grabs the pointer and when I click somewhere outside the window, it doesn't react (thus my window stays always at the top, which is what "I want"), but the problem is that, that the application doesn't catch any events or catches it only when I am inside the window (when I set owner_events to true).
And on Windows it is yet worse: when I click somewhere outside the window, it switches me to the area where I clicked - so this is the same as "without grabbing".
Could someone tell me, what I am doing wrong, or give me a little example on using grabbing in Gtkmm?
For the event_mask, you should include Gdk::ENTER_NOTIFY_MASK and Gdk::BUTTON_RELEASE_MASK so you can ungrab the point when it either reenters the window or when the button is released.
For timestamp, either pass the GdkEvent...::time member, or Gdk::CURRENT_TIME.