THe documentation for accumB says:
Note: As with stepper, the value of the behavior changes "slightly
after" the events occur. This allows for recursive definitions.
In my case there is no recursion, but i want to get updates "right now", not "slightly after". Why there is no special version of accumB? I guess, i'm missing something obvious?
EDIT: In my application I have data Config, which holds various configuration values and a bunch of Event (Config -> Config), which are fired when user changes some value in GUI. Now, i want other parts of my program to access Config whenever they want, that's why i used Behavior Config there. The problem is that when changing event is fired, the behavior still has old value of Config, so i can't observe this change immediately.
If you have a Behavior Conf, then you can make other Behaviors from it via the Applicative class combinators. For instance, it may be that you turn it into a Behavior String which is then displayed in a text field. Once you feed a Behavior to such an UI widget, the widget code makes sure that the new value of the Behavior is displayed.
If you need an explicit indication of when the configuration has changed, then an Event Conf may be more appropriate. You can use the accumE function for that, it will contain the new value.
Related
I am trying to use the option condition to show that by pressing [edit, view & delete] UI Buttons, the admin can execute admin privileges. I am not sure if this is the correct way of implementing it. Currently, my thought process is that, if a button is pressed, the button being pressed becomes the opt fragment condition and then I show what happens if it's pressed within the optional fragment. I have nested an alt fragment within the opt fragment to handle errors that can occur. From what I have read and seen, I feel this is a suitable implementation, but any feedback to improve and make this diagram clearer is more than welcome. Thanks in advance
The question is, what do you mean with [click edit user]? As modeled it is a flag, that determins what option is happening if it is set. Now the first message in this fragment comes from the Admin. That means it is a flag in his or her head. Do you really want to model the brain here?
I rather think, what you want to model is, that there are two possible sequences, either the admin will send the edit user message or the delete user message. Depending on what he or she does, different things will happen next. This can be expressed by an alternative fragment without guards. Guards are optional and are only misleading when you are dealing with human actors, whose actions are often unpredictable.
Maybe you omitted a select option message (that's perfectly legal), whose result could be the flag. But then I don't understand, why the admin will send edit user, after she has already selected an option.
In your nested alternative fragment (shown overlapping in your diagram, but I assume that is just a rendering problem), you have the guard [user found]. This would probably be a local flag of the verify username operation. While it is very much possible, that such a flag exists, it is unnecessary to show it here. The two fragments are distinguishable by their respective first messages username valid and username invalid. So I recommend to omit the guard.
As a sidenote: The operator for the alternative fragment is abreviated alt
I am testing Catel MVVM and I would like to use the implemented IEditableObject. I have got some questions, but the documentation I've found, isn't very detailed in this point.
Did someone have a helpful link, how I have to set this up or how it works, or something like this? Or should I really have a look to the source code, to get these points and get a feeling, how catel do the work.
The questions, that I have got, are these:
What exactly does the method SaveViewModelAsync()?
Where does it save the data, or where can I configurate it?
How can I use it with Orc.EntityFramework6, or do I have this manually?
What's the different between SaveViewModelAsync() and SaveAsync()?
What's the different between CancelViewModelAsync() and CancelAsync()?
I can only cancel the editing one time. If I edit the same ViewModel again, the cancel has no effect anymore.
I think there is only an BeginEdit() missing after the first cancel, like this documentation suggests. Here some informations to this point:
I edit the ViewModel and the Model set the new value
I execute CancelViewModelAsync(), the setter in the Model is not touched
I edit the ViewModel and the Model set the new value. The current value is the original value
I execute CancelViewModelAsync(), nothing happened
I edit the ViewModel and the Model set the new value. The current value is the edited value from step 3, like the View shows
Thanks for help
Lots of questions in a single question, but will try to answer them:
Q1) What exactly does the method SaveViewModelAsync()
It calls IEditableObject.EndEdit on all models that support it (and are decorated with the ModelAttribute
Q2) Where does it save the data, or where can I configurate it?
It just approves the changes to the model, it doesn't "save" anything. So for example, if you are using Catel models, it will commit the changes made by the VM. If you would cancel, it would revert the model back to the state it was when you initialized the VM.
Q3) How can I use it with Orc.EntityFramework6, or do I have this manually?
You have to do this manually. The VM's in Catel work with models, it's up to you when / where you persist them to (e.g. a database, disk, web service, etc)
Q4) What's the different between SaveViewModelAsync() and SaveAsync()?
SaveViewModelAsync is the public method being called and takes care of the plumbing for you. SaveAsync is a method you can override to add additional save logic (e.g. storing in database, update services, etc).
Q5) What's the different between CancelViewModelAsync() and CancelAsync()?
See Q4
I've created a QTreeWidget that displays data that's pulled from 3rd party API calls.
I want the data to be fresh when the user either clicks on or uses the arrow keys to navigate to any QTreeWidgetItem. This means making an API call each time the user clicks or uses an arrow key. Importantly: If the user clicks on the same item a second time, I would like the item to display fresh data (in other words, make another API call and populate with new data, aka refresh)
So far, I've tried:
connecting both itemSelectionChanged and itemClicked to the same update function. This works, but it means that for every click on a new QTreeWidgetItem, I get two calls to the update function (one from itemClicked and the other from itemSelectionChanged), and therefore two API calls that do the exact same thing. Not ideal.
Only handling itemClicked, but then using an event filter to look for Key_Up or Key_Down and then manually emitting an itemClicked. The problem with this is that the key event is handled before the selection is changed, so when using the arrow keys, I'm always getting data for the last QTreeWidgetItem selected, not the current QTreeWidgetItem.
I thought about creating a very short timer or a flag and starting/setting at the start of the update function. If the timer is running or the flag is set, don't run the function (the idea being that the first slot would run, but the second would not because the flag is set/timer is running), but that seems both sloppy and prone to race conditions.
Unfortunately, using a QTreeView with a QAbstractItemModel is not an option.
With that, is there any way to handle both a repeated click on the same item and arrow keys to select new items without double-calling the same update function?
As #ekhumoro pointed out, this can be done by handling both itemClicked and itemSelectionChanged, but introducing some logic so that both functions don't run at the same time.
When a user clicks on the widget, an itemClicked signal is fired. When the user changes selection, the itemSelectionChanged signal is fired. In my case, then, I've created two slots (functions): update (a slot for itemSelectionChanged) and updateFromClick (a slot for itemClicked). updateFromClick checks to see if the selection has changed (this means you always have to store and keep track of the current selection). If, in updateFromClick, I see that the selection has changed, then I do nothing, as update will have been called from itemSelectionChanged. If, in updateFromClick, I see that the selection has not changed, I know that itemSelectionChanged has not been fired, so I call the update function explicitly from updateFromClick.
Again, this is just a long-winded version of #ekhumoro's comment that I'm putting here so the question doesn't go unanswered.
I can't seem to get a clear answer for this: when you change a transient property, and then call save, should the NSManagedObjectContextDidSaveNotification be triggered? In my notification listener, how can I filter out these notifications that are coming from changes in transient properties?
Here's what I'm trying to do: I want to load up a list of contacts in the main thread, and when it's done, I want to read the images in a background thread from the address book and attach them to the contacts. This works fine on the face of it: after loading from the Contacts entity, I use a dispatch queue to loop through all the contacts, find their image in the Address Book, and save them in Contact's "contactImage" property (which is transient). The dispatch queue then successfully reloads the tableview (on the main thread) and the images show up next to the contacts.
The problem is that if I do anything to the contact that invokes a "save" on even ONE of the managed objects (for e.g. I delete one of the contacts), the NSManagedObjectContextDidSaveNotification is invoked for ALL the contacts. I've found that this is because the contactImage property was changed before ... commenting that the "self.contactImage = img;" line makes the issue go away. This is surprising to me, since I would have thought that the save notification would only be called for non-transient properties.
Can anyone confirm if this is expected behavior? Or am I doing something wrong? If it's expected, how do you filter out the updates to transient properties in the NSManagedObjectContextDidSaveNotification listener? I need to do some post-processing in the listener, and I don' want to do it needlessly for transient property updates. I've checked the changedValues dictionary on the NSManagedObject, but it seems to show empty inside the listener (since only transient properties changed, I'm guessing).
Thanks.
Yesterday,
Transient properties have one key characteristic -- they are managed. You can easily add ivars that are not managed to any NSManagedObject. If you do so, they are not subject to -save: notifications.
A related question: Why are you using a transient ivar? They have some specialized uses; primarily, they are used to trigger property updates throughout the model; i.e. the behavior you are seeing.
A second related question: why are you background fetching all of the images instead of lazy loading them from the Address Book? This looks like a case of premature optimization to me.
Andrew
Say I have a custom field type called MyCoolField that I have deployed in a solution. This solution also contains a SPEventReceivers that has overridden ItemAdded, ItemUpdated, and ItemDeleting. All the specifics of this particular field type are probably not super relevant, but one thing to note is that inside of the OnAdded method it attempts to add a series of event receivers to its ParentList.
After this solution has been deployed, I activate a site-scoped feature that does nothing except add a new site content type - MyContentType. Now, I would not expect any event receivers registered anywhere, since ParentList is supposed to be null for site content types.
So in yet another feature, I go add this MyContentType to a list. The question I have is whether I should expect the OnAdded method to get called now (when adding a content type to the list) or does it only get called when adding the field to list/content type? It seems like it is not getting added (the event receivers are not getting registered), but I wanted to make sure that is truly expected behavior and not something else odd going on in this environment.