I'm developing an application that binds a data model and a user interface together through MFC and I'm trying to use the CMFCPropertyGridCtrl to display and edit the data that's extracted from the data model.Then after I finish editing the properities shown on the CMFCPropertyGridCtrl, I need to move the new updated data back to the data model. When doing this, I need to check if the data in the CMFCPropertyGridCtrl is really updated before the data transfer is executed. I achieve it through checking the return value of IsModified method. But after I move data back to data model, the CMFCPropertyGridCtrl doesn't update its properties itself. So the IsModified method will never work since it just compares the current value to the initial value, not the updated value. How can I solve this problem?
CMFCPropertyGridCtrl::OnPropertyChanged is designed to track a change in a property and to reflect the Change to your system. This virtual function is called by CMFCPropertyGridProperty::OnUpdateValue.
Because m_bModified is discussed here to here some words about it, because it causes sometimes confusion:
m_bModified is cleared by the function CMFCPropertyGridProperty::ResetOriginalValue! In this case m_varValueOrig is set back to the property. The original value may changed by SetOriginalValue.
So the only good position to check and track changes is CMFCPropertyGridCtrl::OnPropertyChanged. If a property is changed, IsModified is true. But this only compared to the original value...
If you're updating value and want to see your modifications in bold text, then it makes sense to use CMFCPropertyGridProperty::SetValue and CMFCPropertyGridProperty::SetOriginalValue in initialization phase.
But next time you want to get your value to be updated use CMFCPropertyGridProperty::SetValue and then call manually to CMFCPropertyGridCtrl::OnPropertyChanged( pointer to your property )
That function will call protected SetModifiedFlag() function, which in a turn will update protected m_bIsModified to have correct value.
Related
following scenario:
I have a Firebase database containing a list that is used to create a set of "paper-cards" with dom-repeat:
<template is="dom-repeat" items="{{items}}">
<my-element card="{{item}}">
<paper-card id="{{card.id}}">
...
</paper-card>
</my-element>
</template>
In the UI, the user can add or delete paper-cards, so items also get deleted in Firebase.
Now I realized if I change the CSS of an element (e.g. fadeIn, fadeOut animation) and afterwards delete a card and later add one card, the card still has the CSS state as it was before (e.g. for fadeIn/fadeOut animations).
My questions:
How does DOM repeat deal with elements added or removed? Is not all information of this element "deleted"?
If I delete item #5 (out of 10), what happens to elements 6-10, are they deleted and re-created as "5-9" or "moved/altered"?
Besides CSS, are there any other implications that should be considered inside the template tag? Do I need to manually reset anything?
You can read about the dom-repeat on https://www.polymer-project.org/1.0/docs/api/dom-repeat but what it basically tells you that it tries to be too smart without asking the developer if it wants that behavior. The dom-repeat is heavily flawed because of this.
Polymer is saving performance to doing a dirty check, basically looping through everything and only changing the DOM if the checked values (id, in this case) changes. This means that it will inherit other values.
Basically, it wont update sub-properties. This means that dom-repeat isn't really made for any kind of update.
You can possibly go around this issue by using Polymer's this.splice(). It works like the splice in javascript but sends out an event to dom-repeat to update and where to update. Remember however, that arrays in Javascript are references, so if you take this.items and try to modify it, it will automatically update values the dom-repeat (without updating DOM) and then it will dirty check the update with the new values and not change anything at all. If you want to modify the array in the dom-repeat, then use JSON.parse(JSON.stringify(array) first to get rid of the reference.
Another thing you can do is to use the unique id. If the id changes for that specific card, then hard reset all values and initialize that specific card once again with all it's normal properties (including CSS). That's the workaround I use all the time.
The desperate thing to do, when nothing else works, is to nullify the array that keeps track of the cardset, with this.set('items', []) and then set the property with the new array.
The repeater evaluates the number of items in your array on initialization and stamps that many template instances into the DOM. If you delete an item from your array the repeater is presented with a new array that is one element less, removes the last one and propagates data change to elements' instances.
So if you start with 10 elements and order to delete #5 then element's #6 data is inserted via data-binding into the same DOM node that previously contained #5 data, and so on down the list. The last DOM node for which the updated array contains no data will be removed from the DOM tree.
I have implemented QAbstractItemModel and QSortFilterProxyModel with it as a source model. I have one itemModel instance and several filterModel instances. In each filterModel I have some variable value of which is calculated based on filtered data from itemModel. When itemModel is recreated (all items removed and the new ones are inserted back) value of this variable should be set to default (or just be recalculated after filtering is done).
The problem is that I don't have some list of pointers to filterModel instances to iterate by them. Sure I can create such static list in constructor. But probably MOC did it instead of me and saved such list inside of QMetaObject of this class?
Your filter proxy implementation is broken. The proxies are fully informed of each and every change to the model - that's why the models are QObjects and emit change signals! There's nothing preventing you from changing the "some variable" as appropriate, when the source model indicates that it has changed.
You need to think of your "some variable" as depending on some data (and structure!) from the source model. Every time the source model indicates changes to the dependent data or structure, your proxy must recompute the value - or at least set a flag so that the value might be recomputed lazily when needed.
Ember Data's Adapter saves edited records in different groups of Ember.OrderedSets, namely: commitDetails.created, commitDetails.updated, and commitDetails.deleted.
model.save() from model controller's createRecord() will be placed in the commitDetails.created group. model.save() from model controller's acceptChanges will placed be in the commitDetails.updated group. But I can't find in code where the placement association happens.
I know that they are instantiated in Ember Transaction's commit function (which calls Adapter's commit, in turn calling Adapter's save). Throughout this process, I can't figure out where exactly the records are sorted according to the created/updated/deleted criteria.
I'm not quite clear what you're asking, but if you're looking for where records get added to their appropriate commitDetails set, I believe this is the line you're looking for, in the commitDetails property itself.
Here's the relevant code.
forEach(records, function(record) {
if(!get(record, 'isDirty')) return;
record.send('willCommit');
var adapter = store.adapterForType(record.constructor);
commitDetails.get(adapter)[get(record, 'dirtyType')].add(record);
});
Let's walk through it.
forEach(records, function(record) {
if(!get(record, 'isDirty')) return;
The above says, for each record in the transaction, if it's not dirty, ignore it.
record.send('willCommit');
Otherwise, update its state to inFlight.
var adapter = store.adapterForType(record.constructor);
Get the record's adapter.
commitDetails.get(adapter)
Look up the adapter's created/updated/deleted trio object, which was instantiated at the top of this method here. It's simply an object with the 3 properties created, updated, and deleted, whose values are empty OrderedSets.
[get(record, 'dirtyType')]
Get the appropriate OrderedSet from the object we just obtained. For example, if the record we're on has been updated, get(record, 'dirtyType') will return the string updated. The brackets are just standard JavaScript property lookup, and so it grabs the updated OrderedSet from our trio object in the previous step.
.add(record);
Finally, add the record to the OrderedSet. On subsequent iterations of the loop, we'll add other records of the same type, so all created records get added to one set, all updated records get added to another set, and all deleted records get added to the third set.
What we end up with at the end of the entire method and return from the property is a Map whose keys are adapters, and whose values are these objects with the 3 properties created, updated, and deleted. Each of those, in turn, are OrderedSets of all the records in the transaction that have been created for that adapter, updated for that adapter, and deleted for that adapter, respectively.
Notice that this computed property is marked volatile, so it will get recomputed each time that someone gets the commitDetails property.
I'm developing a Time Tracking system in TFS so we can control how much time is spent in each task. I'm doing it by checking changes in work items states, and recording the time between states.
I'm using WCF and TFS2010 alert subscription.
Then I noticed the State column in the WorkItem table holds a string, instead of an ID pointing to a State.
With that in mind, I noticed I would have to parse each state and check if it corresponds to some string. And then, some day, someone might want to change the State name. Then we're doomed.
But before I hardcore (or put in some random config.xml)... let me ask, is there a table which holds all possible states of a determined work Item type in TFS?
The states of work item types are stored in the process template files. You can export the work item type to an xml file using witadmin.exe and see the allowed values of the "State" in there.
Programmatically, you can use the Microsoft.TeamFoundation.WorkItemTracking.Client namespace to get the WorkItemType object of your work item type, look for the FieldDefinition object of the "State" in the FieldDefinitions property, then get the possible states from the AllowedValues property of FieldDefinition class.
Greetings,
I've been writing some nasty code to support the undo/redo of deletion of an arbitrary set of objects from my model. I feel like I'm going about this correctly, as all the other mutators (adding/copy-pasting) are subsets of this functionality.
The code is nastier than it needs to me, mostly because the only way to mutate the model involves calling beginInsertRows/beginRemoveRows and removing the rows in a range (just doing 1 row at a time, no need to optimize "neighbors" into a single call yet)
The problem with beginInsertRows/beginRemoveRows is that removal of a row could affect another QModelIndex (say, one cached in a list). For instance:
ParentObj
->ChildObj1
->ChildObj2
->ChildObj3
Say I select ChildObj1 and ChildObj3 and delete them, if I remove ChildObj1 first I've changed ChildObj3's QModelIndex (row is now different). Similar issues occur if I delete a parent object (but I've fixed this by "pruning" children from the list of objects).
Here are the ways I've thought of working around this interface limitation, but I thought I'd ask for a better one before forging ahead:
Move "backwards", assuming a provided list of QModelIndices is orderered from top to bottom just go from bottom up. This really requires sorting to be reliable, and the sort would probably be something naive and slow (maybe there's a smart way of sorting a collection of QModelIndexes? Or does QItemSelectionModel provide good (ordered) lists?)
Update other QModelIndeces each time an object is removed/added (can't think of a non-naive solution, search the list, get new QModelIndeces where needed)
Since updating the actual data is easy, just update the data and rebuild the model. This seems grotesque, and I can imagine it getting quite slow with large sets of data.
Those are the ideas I've got currently. I'm working on option 1 right now.
Regards,
Dan O
Think of beginRemoveRows/endRemoveRows, etc. as methods to ask the QAbstractItemModel base class to fix up your persistent model indexes for you instead of just a way of updating views, and try not to confuse the QAbstractItemModel base class in its work on those indexes. Check out http://labs.trolltech.com/page/Projects/Itemview/Modeltest to exercise your model and see if you are keeping the QAbstractItemModel base class happy.
Where QPersistentModelIndex does not help is if you want to keep your undo/redo data outside of the model. I built a model that is heavily edited, and I did not want to try keeping everything in the model. I store the undo/redo data on the undo stack. The problem is that if you edit a column, storing the persistent index of that column on the undo stack, and then delete the row holding that column, the column's persistent index becomes invalid.
What I do is keep both a persistent model index, and a "historical" regular QModelIndex. When it's time to undo/redo, I check if the persistent index has become invalid. If it has, I pass the historical QModelIndex to a special method of my model to ask it to recreate the index, based on the row, column, and internalPointer. Since all of my edits are on the undo stack, by the time I've backed up to that column edit on the undo stack, the row is sure to be there in the model. I keep enough state in the internalPointer to recreate the original index.
I would consider using a "all-data" model and a filter proxy model with the data model. Data would only be added to the all-data model, and never removed. That way, you could store your undo/redo information with references to that model. (May I suggest QPersistentModelIndex?). Your data model could also track what should be shown, somehow. The filter model would then only return information for the items that should be shown at a given time.