In an Delphi MDI application i can use the Tile,Cascade and ArrangeIcons procedures to organize my child windows, this methods only works when the FormStyle property is set to fsMDIForm, How i can produce the same effect in an SDI application, i mean how i can organize my open windows in a non MDI application?
Usually, you don't have to. Users who wish to re-arrange the windows can right-click the taskbar and choose the tile and cascade commands from the context menu. And I've seen TV commercials for Windows 7 showing that you can even just drag windows in a certain way to make them arrange themselves.
If you still want to provide the command yourself, use the TileWindows and CascadeWindows API functions.
You would have to organize them manually by looping through the TScreen::Forms[] list adjusting the Left/Top properties as needed.
Related
I have created a COM Interop Control in C# to use in my PB application. If I add an ole control to my userobject and select my C# object in the painter, then an olecustomcontrol is created and everything works as expected. However, in order to use a 64-bit version of my object when building the project for a 64-bit platform (in PB Classic 12.6) I added an ole control but hit cancel when asked to select an object, so an olecontrol is created and I can use InsertClass to select my object at runtime. This is working for me but I have one issue: when the user clicks in my control, activating it, the toolbar icons on my MDI window disappear. From the research I have done, it sounds like PB may expect the ole object to provide the menus and toolbars, but my PB menu items are unaffected, it is just the toolbar. My control does contain a toolbar (the control is a rich text editor I created to workaround some shortcomings of the built in control) but I have also tried creating a new Interop Control with only a plain text box on it and got the same results. Actually I also tried using one of the Microsoft controls (Microsoft InkEdit Control) installed on my system, and again got the same results.
Does anyone know how I can fix this toolbar problem? (I'm at a loss, but I'm guessing it may be that I need to somehow tell PB to ignore OLE toolbars and/or tell my C# object not to advertise a toolbar.)
Ah, that legacy code we have to support for decades...
The following would take some research and may not eventually solve the problem, but I'd give it a try. I'd implement a "proxy" COM object that'd serve as an extra layer between your .NET OLE control and its OLE container. Such object would be exposed as OLE control to the PB runtime, and as OLE Container to the .NET control, and forward the COM methods calls between the two. It'd be much easier to code this layer with C++/ATL, but it should be doable with bare C#, too.
Then I'd watch the calls made on IOleInPlaceFrame and IOleInPlaceUIWindow interfaces and block those which lead to the undesired toolbar behavior (if any). I'd also limit the set of OLE control interfaces exposed to the PB runtime to some bare minimum.
The implementation details of AxHost and Control classes might be helpful here, as well as the ATL library source code.
This seems a bug. I created a very simple application that retrieves data into ole control and there was no code in any menu items. As soon data is fetched and ole control gets focus the main MDI toolbar disappear. Somebody should report that bug to SAP.
https://answers.sap.com/questions/300798/toolbar-disappear-when-ole-control-get-focus.html
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.
Even though it is not officially supported by Embarcadero there are many examples showing that you can include a FMX form in a VCL application e.g. MonkeyMixer and this SO question.
However, when I create a test application with only one empty VCL form and one empty FMX form, I get two problems:
There are two application icons in the task bar (apparently one for
each instance of TApplication i.e. VCL and FMX)
It crashes when I close the application (when it calls TStyleManager.UnInitialize in FMX.Forms.FinalizeForms).
How can I make this work?
I need this combination as we want our application to be native on Windows, Mac OS and iOS. Therefore on Windows it is a VCL application and the other OS's are FMX using the TMS native components. We have some large custom graphical components that are made for FMX, and they must also work on Windows.
Edit:
I see only two alternative solutions, and I like none of them:
Use FMX on Windows too. I don't like the idea of styled components instead of native. Experienced users can easily tell the difference.
Maintain to sets of our custom components: VCL and FMX editions. That will require some work, and also the graphical features of FMX are much better than VCL.
I've needed to host an FMX app inside a VCL app for display and training purposes. The FMX app is really an Android target and the VCL a Windows 'demonstrator'. The FMX hosting is done using TFireMonkeyContainer hosting the FMX main form. Yes it's got slight wrinkles but it works ok and I'm sure we'll find a way to improve things.
My FMX main form is created at runtime and has visibility of only FMX.Forms. It is then passed to TFireMonkeyContainer and is destroyed by it when the VCL app closes.
I have a really solid computer program that was written for Windows XP. The program still works great and I would like to update the look and feel of the user interface.
At this time, I would like to give the buttons etc. a more sleek, contemporary look. Much better would be to allow functionality of touch and swipe etc. for tablets and such.
Can anyone tell me what tools in Delphi are used to accomplish this? For instance, do I need to change every button and object manually through object inspector or can I update/modify all objects objects within a project using a single set of commands?
You can start by enabling Windows themes, using Project->Options->Appearance from the IDE's main menu. It's on by default since D2007, but won't be on because your app is coming from Delphi 5. (New projects have it turned on by default, but the IDE can't know if you want it enabled or not when importing older projects.)
You can then start looking at adding gesture support by looking into the documentation for TGestureManager and TGesture. There's a TGestureManager for both VCL and FireMonkey (FMX) applications.
Note that for cross-platform support (Android, iOS, and OS X) you'll need to port your application from the VCL to FMX.
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.