How to copy CComboBox data to another CComboBox?
I don't think there is any supplied method to do so, other than use the usual methods (GetItemData, GetLBText, etc) to get the data from one and insert them into the other.
Related
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.
upon construction of QTreeWidgetItem you can pass a list of strings, so when you insert it in a table(QTreeWidget), you get the strings listed on a row. However, from the methods of the table you can also call setItemWidget and set a text widget or any sort of widget to be in that row, but it seems incompatible with having a string list, since the widget is drawn over the strings. There is also a setData method for the QTreeWidgetItem, which sets some data that can be retreived, but isn't visible to the user. Is there a cookie-cutter way of properly using all three data storage methods? Are they even compatible or must I stick to only one?
The Constructor of QTreeWidgetItem is convenient to immediately list the desired content.
When inserting a custom widget in a cell, you need to change its autoFillBackgroundproperty to true, so that it is not transparent. See the QTreewidget::setItemWidget description:
The given widget's autoFillBackground property must be set to true,
otherwise the widget's background will be transparent, showing both
the model data and the tree widget item.
QTreeWidgetItem::setData can be used when already having an item and you want to change one of its contents.
Of course you can combine any of these methods, but it is hard to say, which approach is best without knowing your use case. Just one more hint: If you just need a plain stupid representation of data that does not change, using QTreeWidget is fine. But if your displayed data can change, e.g. objects get deleted, added, changed in various locations of your code, a QTreeView with a custom data model might be a better choice.
Maybe I am doing something wrong here. I am using a treeview control , which I populate with data. The data (integers mainly) are transformed to CStrings for that matter. When the user clicks on an item, I can read the CString, but then have to parse it in order to get the data .
Several times I have changed the way the data appears on the screen ,and then everything breaks, and I need to rewrite the parsing function. I wonder if there is a better way to do this...
EDIT : The treeview is being populated with items from a std::vector. If I could get the treeview to return an index in the vector instead of a CString , this would fit me perfectly.
You can use CTreeCtrl::SetItemData to associate an arbitrary data value with a tree item, and CTreeCtrl::GetItemData to retrieve this value. Typically you use SetItemData to store a pointer to an object, but in your case you could use this to store the integer values directly.
I hope this helps!
If you change the way you set/get your data in the tree, then you will have to change the way you format and and parse it.
Normally, you should only have 2 functions, the setter and the parser, so it should not be a big issue
I don't think there is a way to make it really faster or cleaner.
Is there any way in MFC to change or to learn ID of instance object like *CTreeCtrl.
In my project I have 3 equal bars with tree on each of them. Using pointer to bar I create bars and after Trees on these bars. I don't want to create own class for every bar. It will be bed solution.
So, after I want to use Tree's ID for making DDE. It will be very comfortable for me because class with trees containers already written. Thanks to DDE I will fast create connection between CTreeCtrl and functional class.
I hope you have some ideas about this IDs.
You do not have to create new class to accommodate each object.
I presume that you use Create member of the CTreeCtrl. Create takes ID as the last parameter. Use GetDlgCtrlID member to retrieve this ID.
GetDlgCtrlID is a member of CWnd and CTreeCtrl is derived from CWnd, hence it also inherits this function.
I am using a List Control to display a representation of elements within a vector. When the list is clicked on another control shows information about that element. The index of the element is currently determined by its index in the control, however if I wish to sort or filter the results this will no longer work.
I have been told that I could use a virtual list control, but the MSDN is not very friendly, can someone run me through how I could use a virtual list control for this?
Frankly - tying data (the position in your data vector) to the presentation of the data in the list control (the position in the list ctrl) is something I would stay away from.
In MFC each control has a "Data" DWORD member variable - when coding in MFC I Always called "SetItemData" for each item added and passed in a pointer that the relevant row referred to e.g.
YourListCtrl.SetItemData((DWORDPTR)&YourData);
Then when the ListCtrl item is selected, you just call
DataTypeYouWant* pData = (DataTypeYouWant*)(YourListCtrl.GetItemData(indexofselecteditem));
Or somesuch thing.
Alternatively - if you don't want to use pointers - hold the index of the item in your original vector in the itemdata for your row (just pass it into the above fns).
To use a virtual list control, set the LVS_OWNERDATA style. You then need to handle the LVN_GETDISPINFO notification message (which is sent via WM_NOTIFY).
If you do this, you are entirely responsible for the data, including the order in which it is shown. Therefore it is up to you to handle sorting and so forth.
By far the easiest way is just to use the item data to set/get an ID that can be used to retrieve the original data, whether that's a vector index or a pointer to the data, or even a key into an associative container.
It really depends on the performance you require.
I have personally seen MAJOR increases in performance for lists holding massive amount of data. However it is much more work to implement, thus for simple uses with not so many data I recommend staying away from it.
Basically, what happens with virtual list controls is that you have your data somewhere in some data structure of your own. Since the list view shows only a small subset of the whole data, it queries you for the content to display when ever something happens (redraw necessary, scroll up or down, change the sorting, etc.).
I don't have handy examples for you. But you can look on codeguru, I am quite sure there are very good examples to start from.
The purpose of virtual list controls is totally different: You should use it for performance reason when you have A LOT of items in your list (I'd say 2500+).
In your case, all you need is to store the vector index in the list item data as NotJarvis explains.