I need a very fast treeview able to list and scroll hundreds of thousands of items also with nesting of subitems etc. The standard Windows tree view control (wrapped with Delphi's TTreeView) is not up to the task. It's too slow.
Now I have checked TVirtualTreeView which is as fast as I need, but there is a problem, it does not work at all like the standard treeview but in a completely different way.
I am wondering if some expert using this component can tell me whether it is feasible to encapsulate it in a new component so that it will have properties and methods of a normal treeview but keeping the speed advantage?
If my question is not clear, I will try to elaborate it further.
My solutions for you is:
Add a new frame to your project
Drop a VirtualTreeView on it and align it as alClient
Add methods and properties in order to make the frame to mimic the TTreeView interface
Implement those methods and properties to deal with the internal TVirtualTreeView
Implement TVirtualTreeView events to mimic the TListView behavior
Replace your current TTreeView by the new frame
I guess this will get you close to what you want, balancing complexity and functionality.
Related
There are lots of questions here about XE2 VCL Styles and custom colors for Buttons, Panels, edits, etc, and VCL Styles. As much as I wish the existing questions covered it, they don't... So DB Control Grids appear to be Yet Another Special Case.
In the DB Control Grid VCL sources, it registers a style hook thusly: TCustomStyleEngine.RegisterStyleHook( TDBCtrlGrid, TScrollingStyleHook);
However, that's not what you would descend from if you want to write your own DB Control Grid VCL style hook. If you do, you get the whole control painted like a very large scrollbar.
So how do you custom-theme a DB Control grid? When you disable the themes completely, it seems to still not allow the active row to be custom painted. So I think that one must have to write a custom subclass and override the Paint method, plus write a VCL style hook class, for this purpose.
It appears that one should probably mostly just customizing using the regular owner draw events OnPaintPanel, and that adding that event, if you didn't, fixes the biggest VCL Styles glitch that I see for TDBCtrlGrid, which is that it doesn't ever use the SelectedColor and just paints everything in flat gray or whatever else is the base color. If anyone can confirm that, or tell me otherwise, it would be appreciated.
How can I merge two VCL components together so I can access both of their properties?
For example, I want to merge a TImage and a TPanel into one, I require that the TPanel is the base component, so the TImage will be child to the TPanel.
Is it possible to do this?
I've been trying to do this in Delphi 2010 via Component > New VCL Component but it creates non-visual components when I require a visual component.
What can I do to change this?
If I understand correctly I think you want to merge two components together and expose the properties for both?
If this is what you are looking for, I asked a similar question for joining a TImage and TScrollBox together which can be found here:
Component Creation - Joining Components Together?
SetSubComponent was the key to achieving this, it may be worth while reading the comments and answers from the link above to understand more.
The Delphi language does not support multiple inheritance of implementation, only multiple inheritance of interface. Thus you cannot simply merge together two classes in the way you hope.
What you are proposing sounds a bit odd anyway. Both TPanel and TImage have their own visual surfaces. The only plausible thing I can imagine is that you could make the TImage a child of the TPanel. Derive a new component from TPanel. That component would create and own a TImage. Make the parent of the TImage sub control be the panel. Any properties and events of the TImage control that you want to surface in your control would have to be done manually. This is composition rather than inheritance.
You might use a TFrame to create a component that exists of other visual components at design time, e.g. a TPanel with a TImage upon it. This is probably not exactly what you want: the properties are not 'merged' together, you must design your own properties and methods to make this newly created component behave as you want it to. The functionality you desire (changing visual features depending on the spot of the mouse) needs to be built only once into the frame.
I'm trying to create my first app based on FireMonkey, and I hit a wall.
The only virtual list control I can find is tGrid.
This component is pretty good, but I can not figure out how to extend or customize it.
I get that there is tCheckbox column, tImage column etc, but what if I need a ButtonColumn or something like this?
Also I would like to style a row, based on the state of the data it represents.
An Example: if the data that is represented in the row has "Error=True" it should be displayed in red.
Has anyone got a similar problem? Or found alternate virtual list/grid components? Or even just some tips on use of the tGrid component.
These components are pretty essential in all database apps so it should be a pretty common request.
Also just as a note, I don't think the TGrid supports Drag & Drop of rows?
I have looked at
Firemonkey version of VirtualTreeView
and
Firemonkey and large amounts of data
If you look at the sources, TCheckColumn is only 15 code lines. If you need to create your own column descendant class it's quite straightforward.
This is one solution, otherwise you can dynamically create some components in your cells and then cast the children when checking the props (TColumn.CellControlByRow() return a TControl and the children would be what you have put in there).
As you want to 'style' your row I would suggest you to write your own TColumn class, even if you can do painting in the OnPaint Event.
In this article there is an explanation of how to use TFrames as an alternative to TTabSheets in a Delphi PageControl.
I've been pondering a similar exercise, which the above doesn't seem to provide the solution for, and for which my solution seems to be overly complicated.
The requirement is for a tabbed interface, where each tab can be one of a number of different designs. Each design is implemented as a TFrame.
Due to the nature of the application being designed, we may have multiple copies of any frame open at any particular moment (with the content of each tab differing, but not the design) so that the user can compare the details of 2/3 different items at the same time.
For example in one session we may have 3 tabs open, all of Frame design A.
On another occasion we may have 3 tabs open each of Frame A, B and C.
The design needs to be flexible enough that we can add Frames to the design on request.
At the moment the solution that I have is to have separate TLists managing each type of Frame that we have open, with perhaps a master TList to keep track of the tabs that are open. As I said, over complicated.
Does anyone have a suggestion of how this could be handled more simply?
I'd probably leave out the master TList of frame instances.
If you need them you'll be able to get them by interrogating the TPageControl directly or through each of your individual TLists for each frame type.
Apart from that your approach sounds reasonable.
I have an application that manages frames on a single panel with my own menu control to control which frame is visible. When I need to make a frame visible I simple set visible:=false for every frame on the panel except for the one that I want. I am in control of what goes onto the panel so I know that at the very least each control is a Tframe and I can get to each frame by iterating over the Panel's Controls property. I then use interfaces to communicate between my main form and my frames.
Now if you want to use a standard windows tabbed interface you could still use the page control as you have suggested, you know that each TtabSheet has a single Tframe on it and you can check it's type and work with it as required. I don't see why you'd need a Tlist because if you really need to get at the "list of Tframes" you could build it dyamically anyway by iterating over the TtabSheets in the page control.
An alternative which would work similarly to my first approach, but gets you nice Windows tabs, would be to use a TtabControl instead of a TpageControl. With the TtabControl you basically just get a Tstrings instance (in the Tabs property) which represents all of the tabs. Since it's a Tstrings you can associate an object (ie your Tframe) with each item and hence each tab. When you click a tab you hide everything and show the correct Tframe. You also have your list because it's attached to the TtabControl via the Tabs property. You just have to handle the visibility of the frames yourself.
We use a TPageControl and create runtime a TTabSheet descendant, which has a new property for our own TFrame (we do not need to scan through .Controls or .Components to search our frame each time).
yesterday I've started discussion on "MDI vs tabbed interface". I've asked whether should I continue developing my app as MDI-based, or should I embed the child forms into tab sheets.
Someone pointed that I should use TFrames instead... My question is: why?
What are pros of using TFrames when embedding the form over TFrame? So far I don't know any, switching would only require me to rewrite some parts of code...
(I'm not going to use embedding at design time anyway!)
Thanks in advance
Answering the comment to provide a reason why to use frames:
I would consider frames to be building blocks of the GUI, with design time combination of existing components to more advanced components. Before Delphi 5 one would have used a TCustomPanel descendant with child controls and registered this as the new component, ready to be dropped onto a form. Frames allow for the same thing with less hassle.
They allow you to concentrate on developing exactly the functionality you need, and nothing more. Done right you can then embed them into tab control sheets, into modal or modeless dialogs, into MDI child frames and into standard frames. You can even add several of them into one form - something one would probably not do with embedded forms. The point is that for maximum reusability a layered approach is often necessary, and frames help with that.
A frame is fit for embedding from the go. A form has to be adapted to not show a caption bar and border, normally one would override the CreateParams() and adjust the window style accordingly. There are a lot more form properties in the inspector that just don't make sense for an embedded form. IMHO one should use the most basic and generic entity that suffices. A form just is much more than a control container for embedding.
OTOH I don't know of any disadvantage of embedding a frame that embedding a form wouldn't have.
Edit:
There's a comment regarding events like OnCreate or OnShow that frames don't have. Actually, I'd consider that another advantage of frames, as event handlers don't have parameters, so a lot of stuff gets hard-coded in forms, necessarily.
Consider the case of per-user settings: in OnCreate there's not much information available, so one invariably ends up using a constant or the name of the form for the INI file section, making it very hard or even impossible to reuse the form or to create several instances of it. With frames on the other hand a method LoadSettings is the obvious way to do it, and it can carry the necessary parameters. That way control is returned to where it belongs, to the container of the embedded frame / form. Reusability is only possible if the behaviour can be adjusted from the outside.
For contained objects that are not components and need to be lifetime-managed, there are for example AfterConstruction and BeforeDestruction.
Maybe you will find some answers in this thread: gui-design-multiple-forms-vs-simulated-mdi-tabs-vs-pagecontrol
Frame use the fastest load and without delay when creating the frame.
But the frame should be has a parent to embedded it. Disadvantage with no onCreate or onShow event has been triggered. but you can call with message for trigger onShow event like this one :
put on private section of frame:
procedure CMShowingChanged(var M: TMessage); message CM_SHOWINGCHANGED;
and then create the code like this :
procedure TFrame1.CMShowingChanged(var M: TMessage);
begin
inherited;
if Showing then
begin
// .... put your code for onShowing is triggered
end
else
begin
// .... put your code for onHiding is triggered
end;
end;
Hope can helping you to consider embedded frame for GUI.
You may consider combined with PageControl to control your frame opening.
Manz
I had same decision few years ago for one of our applications, we wanted to make it looks embedded forms, first I used the Frames and I wrote a class to manage it.
Later I found TLMDDisplayForm component from LMDTools, which making embedding forms inside it very easy task, it reduced the code used and we have more features.
one of main goals that we changed from frames to Forms was missing some events of TForm like: OnCreate, OnShow, OnActive which we use for some tasks in our applications, beside missing some properties such as: ActiveControl and other things I don't remember.
If you would like to go with Forms, I suggest you to use LMDTools which make the task easier for you, beside the basic version is free :-)
For dynamically inserted forms/frames I personally prefer to use embedded forms over frames. Several versions back when one would edit a frame which was set to alClient, the frame would resize between edits and any controls which were aligned specific to the right of the frame would change position. When using embedded forms this didn't happen so I made the switch. I believe this issue is now fixed with later versions of Delphi.
I strongly agree with the points Mghie made earlier regarding the inability to pass information to the embedded form through notification events. To solve this I generally implement a series of interfaces in each embedded form for communication. This really simplifies the code, and allows for more generic implementations where you have a single "container" that will be dealing with many different types of embedded forms/frames. A few examples of this are available on my blog as part of the wizard framework I designed.
I think both should be used. For example, I have a "standard" frame that has a dbnavigator, dbgrid and datasource components which is very handy for the typical data browsing. Instead of inserting such components every time, I insert a frame that also has the ability to export its data (with JVCL :D) to several formats...but I know what I want to display at design time, so I suggest a very easy rule: if it is known at design time, use frames, otherwise use embedded forms.
However, keep in mind that forms were not designed to be embedded. Using them like so, its unnatural (as a vampire states when she buries her 80 old year daughter and she looked like 30 :D). The embedded form knows little about the one that owns it and can also (logically) assume that is not embedded.
Complementing that, a frame is a component, and so, when embedded (owned by) in a form, the form knows about it and the frame knows about the form (can use its methods and properties. An embedded one can also do that but requires extra coding)
Perhaps Embarcadero could give us a hand by creating a TEmbeddableForm or an interface for such purposes
Regards,
Alvaro Castiello
Frames are good when you want to repeat a "sub-form" multiple times in a form. I'd not use them for tabbed interfacing, as the embedded form is a better solution for MDI/Tabbed interface use.