I've used TActionLists in D7 for many projects, one for each TForm where it seemed relevant. Now, starting a new project i XE2, the users require a Ribbon, which seems to require a TActionManager.
Reading online and the documentation doesn't give me a clear idea on how to utilize the TActionManager in the way it was developed. My questions are:
Am I supposed to put just one TActionManager in ex. TDataModule or am I supposed to stick by my usual procedure, and put one on each TForm?
Should I use it in conjunction with TActionLists, or is that only for existing projects, where the TActionManager is introduced later?
Anything to be aware of when using TActionManager in SDI or MDI applications?
Links to examples etc. are appreciated.
Thanks,
/Mikkel
(1) Although conceptually, it is preferable to limit components on forms to visual components and components that are very closely tied to presentation, moving aside all others to data-modules, TActionLists and TActionManagers are the exception to the rule for a practical reason. If you put an actionmanager on a datamodule and have action bars on a form with buttons and menu items linked to contained actions of the actionmanager, the IDE will sometimes destroy all your actionbar hosted controls. To save frustration, put one actionmanager each form.
(2) Once you start using Actionmanagers, there is no reason to use ActionLists. An actionmanager is like an actionlist on steriods. While you could have a mix, it seems simpler to have just all of one kind in a project. Compare the look and feel of an actionband main menu with an XPStyle style setting, with an old fashioned main menu.
(3) There is no issue with using actionmanagers in SDI or MDI applications, that I am aware of.
(4) ActionBands are more than a decade old now. Here are some links authored two great Delphi luminaries...
http://www.blong.com/Conferences/DCon2001/Actions/Actions.htm
http://www.stevetrefethen.com/wiki/Default.aspx?Page=Delphi%20ActionBand%20FAQ
http://cc.embarcadero.com/Item/19272
Related
I am creating an application which makes use of several TTabsheets (from the TPageControl component). Is it possible to prevent a component (in this case a tab) from being created during the program startup? I want to manually create the tabs at a later stage.
This is not a dynamic component. It was created in the Delphi 2010 IDE.
Thanks!
If you include components in the designer, then they will be created when the form is created. Nothing you can do to stop that.
The logical conclusion is that you need to create the components at run time. One obvious way to make that easier is to put the components on a frame and create that at run time. That will allow you to group related components and do the visual design and property specification at design time, but then postpone creation until you know you need them.
I have in a old project, standard menus on my forms. The menu items are populated by TActions that I have made using the TActionManager.
I am updating this old project and would now like to change the appearance of my menu to XP Style as set by the TActionManager, so it can match the TToolBars on my forms which have changed to dsGradient.
Is there a non lazy way of making this transformation?
Otherwise it means I have to manually go through my forms, remove the TMainMenus, drop a TActionMainMenuBar on the form and then begin creating the TActionBars to populate the menus again, which I will be honest with you right now I don't feel like spending so much time doing this.
So if there is a way to automate the conversion somehow I would be interested to know, then I don't have to spend so much time manually changing them.
Equally, if the above can be done without manually making the changes, I would be interested to see if it is possible to reverse convert, eg TActionBar menu to TMainMenu?
If I must do it manually then so be it, but if there is a quicker better option then I really would like to know.
I strongly suggest you to study the following converter utilities by ChoosPill :
TB2KImpTb97
TB2KImport
They are distributed in source code and support the import of all relevant items and properties from stock VCL components TMainMenu, TPopupMenu, TMenuItem and TToolBar to Jordan Russel's famous Toolbar97/Toolbar2000 components respectfully.
You can also consider to take a glimpse at TBXLib converter source code .
You can also consider delving into TdxBarConverter's source code if you are a DevExpress registred user.
They can serve as a good starting point for you.
After years of Delphi development I now have hundreds of forms shared throughout our Applications. Compilation ranges from Delphi 7 through to XE, thus one form might be opened in any IDE. The well-known Explicitxxx property addition after Delphi 7 has solutions to avoid a form accidentally acquiring properties that earlier compilers can't process (e.g Andreas's DDevExtensions) but I'd like a more positive 'switch' that prevented Delphi from making or saving any form modifications at all. Period.
Of course you could use the read-only flag, and a version control system provides additional means particulay of seeing that such a modification has occured. What I'd really like though is a {$LockDFM} switch that I could put in the form's unit, or a context menu option when viewing the form layout.
Can anyone think of a neat way of achieving this?
Thanks
The only thing I can think of (other than the read-only/VCS options you mentioned) is the Edit menu's Lock Controls option. This sets a flag that prevents controls from being moved around. I'm not sure how much good it would actually do, as I've never tried it; I just know it's there.
Helo
I am pretty sure that Delphi has no such a thing. I have been searching for a solution to this problem as well.
But, theres one thing you can do: You can write your own Delphi addon using OTA (Open Tools API). I know that there are a few classes which are able to notify you when something are about to be saved. You can intercept this event and decide if you wanna save it (in your case, if it is a DFM).
BTW, if you have plans to do such component, tell me. :)
EDIT:
I have found a piece of code that may help you. Extracted from http://www.gexperts.org/otafaq.html
TMyFormNotifier = class(TNotifierObject, IOTANotifier, IOTAFormNotifier)
protected
procedure FormActivated;
procedure FormSaving;
procedure ComponentRenamed(ComponentHandle: TOTAHandle; const OldName, NewName: string);
end;
In design time there is Edit->Lock Control.
LE: this is only for resizing/repositioning the controls on the forms. Concerning the ObjectInspector I don't know if there is anything that can 'lock' the values set there(so the developer can not change them).
Basically, no. Aside from the f'ing (pardon my french) explicit size and position properties which IMO never should have been in the .dfm, there are some third party components will change stuff just by you viewing the form. F.x. TMS components will update a version number even if you didn't change a thing since the previous version of their components.
My team is currently thinking of moving our existing MDI-based application to a more modern, docking-based approach. We're still thinking, but we'd like to move it to something like VS2010's docking and visual look:
This has the following features:
Shows a blended outline where the window will dock
Docks into tabs, as well as side-by-side
Allows docking by dragging and releasing over an image showing the dock position (I call this a 'docking widget' below)
Looks pretty good too (theme / UI-wise)
I am having trouble finding a good-quality docking library to use with RAD Studio 2010 and am seeking advice on either what library/ies I haven't found, or how to use the ones I have found to achieve something like this.
Update: I ended up buying AutomatedQA's docking library. I think it's the best. More details below in the section about it.
Update 2, July 2011: This question looked at every single docking library available for Delphi/C++Builder, so I'm trying to keep it up to date. Two changes that I'm aware of:
SmartBear, who now own AutomatedQA, have end-of-lifed AutomatedQA's docking library. This the one one I recommended buying. They are considering open-sourcing it.
The one problem I had with DevExpress docking (that made it not worthy buying) was its lack of support for VS2008/10-style docking, with a docking widget, transparent overlay as you dragged, etc. They are now implementing it. Because of this, and since AQDocking is no longer being sold, if I asked this question now my accepted answer would be to buy DevExpress Docking.
I've found the following libraries. Here's an overview:
Inbuilt VCL docking
This allows forms to be docked on other forms or TWinControls, but appears to be quite basic. Forms drag using an XOR painted outline, which works very badly on Vista and Win7. There is a TTabDockSet control for tabbed docked forms, but I can't figure out how to control how the docked forms' titles render once docked. I think implementing docking side-by-side will have to be done manually, creating new docksite panels on the fly. The RAD Studio IDE's docking windows are a bit slicker than this (transparent rectangles when dragging a form, for example) which is odd, since I thought it used the VCL docking support.
JVCL docking
This looks a bit more of a decent solution that the inbuilt VCL docking. It supports docking on any edge or the client, and shows an alphablended rectangle where the form will dock.
It appears to be quite buggy (dropping a second form on top of a first is allowed, but freezes the program) and has no inbuilt tabbed dock support or any kind of drop-location widget.
LMD Docking Pack
This looks promising: while it doesn't seem to directly dock forms, it has docking panels and controls / frames are placed on that. Existing forms could be migrated to frames. It also has a docking widget and tabbed dock support.
However, the demo seems to be quite unreliable. I've got the latest evaluation version installed, and creating a new project with a dock site and several panels and pressing Run causes the following:
This is crashing in the form component streaming. Visually examining the DFM file doesn't show anything wrong, but there's an opaque binary blob for the layout information that may be causing it. This is not especially encouraging in an evaluation version.
DevExpress ExpressDocking
I had high hopes for this: I've never used any DevExpress controls before but they have a good reputation. But their demo program was really disappointing:
The control is flickery and doesn't seem to theme well with Windows, even using the XP style. It does have tabbed docking but it uses an XOR-ed outline - something that doesn't work well on XP or Vista. It also does not have any sort of docking widget. Frankly, it looks like it hasn't been updated since the Windows XP days. Update July 2011: This is being improved.
AutomatedQA / SmartBear docking library
This is the most promising of all the libraries so far.
I regularly use AQTime, an excellent profiler which appears to be written using their own docking library, and it works well. However, the latest version of the docking library trial download is for RAD Studio 2009, and the advice given for installing into 2010 is that it's unsupported, and you should recompile the source. The demo doesn't come with source, and we don't have RS2009, and the installer refuses to install unless we do, and even if we manged to get it to install we can't use it since we would need to recompile the non-existent source.
I've been in touch with their support team, and they pointed me to this thread. I also found another thread with customers asking much the same thing. I've replied and hope to hear better news. I'm not keen to recommend we buy a product I can't evaluate, especially when it's not supported for our IDE.
Update: I have ended up buying this library. In spite of problems evaluating (it works in D2007, and I had a copy of that) it seems the easiest to use of all the libraries, and also the most powerful - it's easy to write a theme for it, for example. I'd definitely recommend it if you need to select a docking library too.
Update July 2011: This library is no longer being sold, but may be open-sourced soon.
What have I missed?
That's everything I've found so far. What now?
Have I missed any good docking libraries for Delphi / C++ Builder / RAD Studio 2010?
Have I missed any features in the libraries I've lookd at so far? An answer like "You missed FooBar" or "JVCL does indeed have a docking widget, and you can use it like so..." would be pretty awesome to hear.
What would you recommend as my next step?
Thanks for your input :)
I am a jedi JVCL developer, and I have used JvDocking in my own commercial in-house projects, and found it to be solid and reliable.
Also, it's free. It's easy to extend. It creates a look and feel about the same as visual studio 2008 era docking.
I haven't found a single library that does everything that I would like, so after doing some experimenting I found that I could do almost everything I wanted by using the Native VCL Docking (NVCLD) controls with a series of custom modifications and some additional controls.
The following is a list things that I've run across in getting the NVCLD to work the way I wanted. I haven't had many problems porting between versions, but that's because I've got the src as well.
If your not looking to roll your own or you really want to use a 3rd party library then you can probably stop reading the rest of this. :)
Additional Components:
TDockPanel
This heavily modified docking panel is the workhorse my system. I found the original on the net but have modified it since to provide a little greater flexibility for my needs.
Custom Docking Forms (Base form)
By using a custom base class for my docking forms and inheriting it when needed I have less modifications to do on all of the descendant forms.
Custom Modifications
These are modifications to the .pas files of the NVCLD components themselves. Most of these modifications no longer have to be done because of some enhancements made to the base controls starting with D2009. You should be able to just create a new descendant and implement the changes in the there instead of modifying the default src files directly.
Transparent Docking Forms
By default (pre-2009 for sure) the NVCLD doesn't support the transparent form movement. There was a JVCL patch released a couple of years back that added that support to the JVCL which was simple to incorporate into a NVLCD patch.
Docking Manager
The default docking manager (pre-2009 for sure) didn't allow for newer/custom button images or docking header changes. This was rectified in D2009 I believe when the necessary methods where made virtual.
Tabbed Docking
To support the Additional docking components I needed to modify the DockTabSet.pas file to support additional docking properties used by the additional components. Most of this was corrected when the Docking Manager was modified as mentions previously.
As I stated most of these changes I made directly to the Delphi Src files and you shouldn't need to do that for newer versions of Delphi. My point is that with a little bit of work up front you can have a fairly robust docking system with out resorting to using a 3rd party library. Not that there is anything wrong with any of them, but I prefer not to use them unless I have no other choice or don't have the time to make it work my way.
I have used JCL, I have LMD, DevExpress and Automated QA Docking Library.
The closest you will find that will meet your need is the AutomatedQA Docking Library. I use it in my work for one of my projects.
Your next step, buy the AutomatedQA Library :)
from a Happy Customer.
I currently have an SDI application that is build with Delphi 7, I want the final user to choose the type of interface between SDI and MDI at runtime. my question is how can I change the behavior of the application between SDI and MDI at runtime?
Currently I know a couple of applications build with delphi that allow this: EMS SQL Manager and TOAD.
thanks in advance.
Download the Jedi JVCL and install it and look at the Demos for JvDocking "docking in code". They do this exactly.
They mean that you do not actually use the FormStyle=fsMDIChild unless you want lots of problems. MDI is "emulated" when you need it by docking in code.
Do not convert windows into frames. This is a bad solution.
For an MDI-like environment, that does not have the MDI problems, use a docking solution (components either commercial or open source that support docking). I use JvDocking which is included in the JEDI JVCL, which is free and open source.
You use your forms in both "docked" and "undocked" (floating) modes, and this gives you a docked IDE look and feel (VIsual Studio and RAD Studio), and an undocked IDE Look and feel (RAD Studio in undocked, or classic delphi 7).
I would convert my current windows into frames and put these frames with align=alClient into either mdi child windows or normal windows as configured.
But beware: I have never actually done this, so there might be problems that I don't know about.
At runtime set TForm.FormStyle either to fsNormal or fsMDIChild depending on if you want SDI or MDI.
Like #WarrenP's solution, I strongly recommend a docking-based solution. It should be said that you don't need to use Jedi VCL to achieve this. As an example, here's a very simple (all-native-vcl) component I've produced which allows you to simply drop on as many instances to your form(s) and set their alignment to enable docking (and tabbed docking) in those regions.
MDI itself is an accident waiting for a place to happen. There are solutions available to achieve the "MDI look and feel" without using MDI itself, though I've yet to encounter one I'd consider "neat" (probably for a lack of looking).
Ultimately you should probably question the wisdom in providing MDI as an option. Docking (with or without the ability to undock, and especially when Tabbed Docking is a user-determined choice) feels more modern, and (done properly) can be far more flexible and intuitive than MDI ever was.
Just my 2-pence worth.