I have a TreeView control which uses multiple different types of embedded editors at each node. I'm having a problem with one editor in particular which has EditorButtons on it. There is code that changes the Visible and/or Enabled state of the EditorButtons, but although this code works fine for this control when it is not in the TreeView (just on a normal WinForm object), it doesn't want to refresh the visible status of the control when within the TreeView. I'm sure this has something to do with the nature of how embedded editors are handled, but I've tried everything I can think of from a direct Invalidate and Refresh call on both the embedded control and TreeView parent to my own DrawFilter. Certainly there is some event or method that I'm missing that is failing to force the embedded control from reflecting the current properties of the Editor Buttons? Thanks
Okay, I get what you mean about the image, now. It should be possible to change the down arrow inside the DropDownEditorButton into an image using a CreationFilter, but if you already have it working with a regular EditorButton, then there's probably no reason to revisit the issue.
I understand your confusion about editors and how they work. It's very common because they are, in fact, confusing. :)
It's a result of the fact that the editors weren't in the initial design of the grid, but were retrofitted later. It's often difficult to know which properties and events on the editor control are useful, and in which cases you have to use the grid events and properties. Generally speaking, you should try to use a grid property or event whenever possible. But in cases like the editor button events, there are no such events on the grid, so you have to use the events on the editor control.
I will keep this case open a few more days, just in case you run into any problems getting the buttons from the cell.
Hi Mike. I apologize as I realize that there are a lot of parts to this and it is difficult to get it all communicated effectively without taking up too much of your time. Thanks for your patience. I'll try to explain a bit more of this to hopefully clarify for both you and any future person trying to read through this.
The Appearance object I was referring to is the EditorButton.Appearance. I wanted a custom image on the DropDownEditorButton. This is easy to do but the image is always accompanied by the dropdown arrow as well (which I didn't want). THat's where I was using the idea from the other post to just use a normal EditorButton so that I can set its image without the dropdown arrow showing and then "simply" call the .DropDown of the other EditorButton which is configured as a DropDownEditorButton.
The event raising process I'm referring to is the idea that I raise an event from the editor (eg. DisableEditorButton) that is then handled by the Tree (programmatically referenced through a AddHandler call). The handling method can then take the appropriate action to disable the editor button on the Resolved Editor for that node. Does that make sense?
It is interesting to think of your approach on the editor vs. editor control. I hadn't considered that. I don't think that will work in this particular case, but it's good to keep in mind.
I'm attaching a clipped image that shows what I have now - it shows two date controls embedded in tree nodes, followed by the custom combo control I'm referring to. The custom control has a button on the left (an "X"), a normal combo drop-down on the right, a DropDownEditorButton on the right (which includes a "bolt" image and the drop-down arrow, and a magnifying glass button on the right which is a normal EditorButton.
I realize the button events are firing on the Editor control - that's where things get a little confusing for me because I thought that if I could handle the event within the Editor (for example, an EditorButton click) then I could respond to that event within the editor. In truth I can, except (apparently) when the action I want to take involves changing something within the editor itself (such as the appearance of anything in the editor control or forcing another DropDownEditorButton to DropDown) at which point that needs to be handled back on the Tree, right?
So if I have understood this correctly then I believe you have answered the question and I just need to try to see if I can get it to work by handling the editor updates back on the Tree rather than within the editor.
Hi,
Now you're really losing me. I still don't understand what image you are referring to. You mentioned the image property of the appearance, but what appearance are you referring to? The Appearance property of what object?
If you are trying to access the button that exists inside the tree cell, then it's no different than accessing that button inside the grid cell. You can't get to it via the UltraTextEditor control (or whatever editor control you are using). You can only access is via the editor, which is only exposed through the cell.
Not sure what you mean by "raised some type of event on the editor." Events are actually a different story, especially the button events, because all of the editor buttons events DO fire on the Editor control. They have to, because the tree doesn't even have any events for those.
Also, I was not necessarily suggesting that you need a single editor for every cell in your tree. But you could create an editor instead of an editor control. Right now, you are creating a control (UltraTextEditor, I think) and you the tree is using a copy of that control's editor. But you don't really need the control itself, nor do you need the editor that the control is using for itself. All you need is the editor that is being used in the tree cell. And for that, you could just create an instance of the editor. In the case of UltraTextEditor, this would be an EditorWithText. But now that I think about it, this is probably not a good solution in your case, because you need the UltraTextEditor control in order to handle the button click events.
I realize you are trying to keep things simple here, but they've gotten pretty complex already, so if you want to try to explain to me what you are trying to achieve overall, i might be able to point you in a better direction. :)
Otherwise, I'm pretty sure I've answered your original question about how to access the buttons so you can hide or remove them. Or do you still need help with that?
Thanks for the very detailed reply Mike. I did have my head wrapped around "most" of the use of the editors, but your explanation definitely clarifies some items. I was hoping that I would be able to do what I wanted within my custom editor's code (thinking that it was being referenced by the Tree), but it sounds like I can only access it from the Tree as the Tree is dealing with a copy of the editor on instantiation. Though it's interesting that a normal DropDownEditorButton can display, but when calling to display it from another button it won't work! I was thinking that the UltraGrid code could be applied to the Tree, but I just didn't think it would be necessary if I was using a custom coded control that I had direct access to the code execution (vs. the other samples I saw were using the Infragtics pre-built controls as editors, so it would be presumably more challenging to have direct access to the underlying properties and methods without getting into using the Infragistics source code).
So if I raised some type of event on the editor that is handled on the main form, and then handle that event on the form by referencing the TreeView resolved node editor, then I can theoretically access the buttons to update their appearance (visible/enabled, etc) or force the dropdown?
By the way, the image I was referring to is the image in the Appearance.Image property. It takes up too much space and looks too busy so I prefer the DropDownEditorButton to use only the image without the dropdown arrow (that would be a nice feature option: EditorButton.DisplayStyle - DropDownButton, DropDownButton and Image, ImageOnly)
I don't know if it would be possible to create a single editor that would do what I needed. While I realize it's likely less efficient to create a control for each node, the Tree is actually quite small with typically a dozen or less nodes. We use this approach to dynamically create a list of choices to the end-user, and each of the choices pulls from different requirements - from simple checkboxes and textboxes, to more complicated combobox and custom editors (that are, themselves, based on UltraComboEditor or other controls like DateTimeEditor). It looks and works exactly how we want most of the time, though I will admit that dealing with the Editor/EditorComponent has been a little tricky at times. Based on the diverse need of the types of data and type of editor we need to share with the end user, combined with the fact that we don't need dozens or hundreds of nodes, I think our approach is reasonable. I'm not sure what type of Editor that you have in mind that would still meet our requirements.
Thanks
I'm a little lost on what you mean by "I was trying to use a DropDownEditorButton initially but didn't want the dropdown button to appear - only the image."
What image are you referring to?
Using a completely new control as the EditorComponent for each cell probably isn't very efficient in terms of memory. You might be better off creating an editor, rather than a control for each cell. That would also make hiding / removing the buttons a lot easier.
My initial guess is that you are probably having the same problem as the poster in the other post you linked here. You are probably accessing the button in the editor control, rather than the button being used by the tree. So you have to get the editor from the cell and then get the editor button from that editor.
It might be helpful for you to understand a little about how editors worl. Let's look at a hypothetical example:
Suppose you have a tree and an UltraTextEditor control and you assign the UltraTextEditor control as the EditorComponent of a cell in the tree. The UltraTextEditor control is something of a shell which provides a wrapper around the editor. The editor does all the real work displaying the text and allowing editing and providing the buttons, etc. The editor is abstracted in such a way that it doesn't really know what text to display or what the buttons do it gets this information from the owner.
When you interact with the UltraTextEditor on the form, the editor's owner is the UltraTextEditor control. So the control's ButtonsRight collection tells the editor which buttons to display and the UltraTextEditor control's Text property provides the text.
When you use the tree, the tree provides the owner. The tree tells the editor what text to display (based on the value of the cell). The tree doesn't have any properties for the buttons, so the buttons are created based on the UltraTextEditor (which hands the tree a copy of it's internal editor). But once the copy is made, changing the properties on the ButtonsRight of the UltraTextEditor won't do anything.
So you need to access the local copies of the buttons that are created by the editor itself, which is what the code in the linked post does. That post is for the Wingrid, of course, but you could easily do the same thing using the UltraTreeCell instead of the UltraGridCell.