Using Delphi Tokyo with Windows10.
I would like to use Expanders in my VCL App, ie, to quickly show/hide info and to declutter UI's. They are pretty common now and done very well elsewhere, eg, in Microsoft's Fluent UI and also in Android, in fact they are part of Android's Material Design.
Delphi does include the TExpander Component for FMX, but for some reason does not have one for VCL (yet).
How are others handling this in their VCL Apps?
Is there a way to access and instantiate the Expander component that Windows itself uses with an API call?
Are folks just writing their own? If so, I would welcome a link to a Github repo or equivalent so I don't have to reinvent the wheel. I am not asking anyone to write anything just asking if anyone's done this and for a pointer. If not, I will write one myself and share.
I know there is the TCategoryGroupPanel, it just isn't very snappy and is somewhat awkward. I also know that TMS sells something like this but unfortunately this will not work.
Alternate suggestions for getting an Expander Component into a Delphi VCL App would be most welcome too.
Thank you
There is no native Windows control for collapsible panels (for use in VCL application), but you can use the mentioned TCategoryPanelGroup. In my opinion I cannot say there are issues that could prevent you using that control.
Related
I don't understand LiveBinding's purpose. I would like to know which are the cases in which LiveBinding is most valuable. Embarcadero's manual describes it: "LiveBindings is a data-binding feature supported by both the VCL and FireMonkey frameworks in RAD Studio. LiveBindings is an expression-based framework, which means it uses binding expressions to bind objects to other objects or to dataset fields".
Thanks but I still don't know more than before.
I have seen some video in which a guy spends 12 minutes and hundredths of clicks to connect the caption of a TLabel to a TListBox control. When the user clicks an item in ListBox the name of the item is shown in Label. I could have done that with a single line of code (few keystrokes and no mouse clicks).
I am not criticizing LiveBinding. I am saying that I don't understand where it is helpful. I am missing something. Since it is not doing something that cannot be done from code, it means it's doing something that can be done from code, but visually and much much faster. I admit I haven't invested a lot of time in this topic but everywhere I look I see a terribly convoluted way (come on, you really need 5 extra controls to make LiveBinding works?) to do a simple task.
Also, it seems that LiveBinding was mostly designed for DB. All examples will include some kind of DB connectivity. But I am expressly interested only about the cases where I can use LiveBindings and there is no data set/DB involved. I am not using DB that much.
I doubt v. much that anyone would use live bindings if they could use traditional db-aware VCL components. However, that's not an option for non-VCL projects (Android, Apple, etc) and live bindings is the only Emba-supplied option for delivering data to those from TDataSet descendants.
An advantage of live bindings is that in addition to the Android and Apple targets, you can use them in Windows apps, so conceivably you could write the same (FMX-based) application for all three.
Libe-binding can also be used in VCL applications, but tbh, I can't imagine why anyone would use live bindings if they were only targeting a Windows DB application, as they are much slower than the traditional db-aware controls, especially multi-row ones such as grids.
I have not tried myself, but because the implementation of live bindings is interface-based, its potential use extends far beyond DB applications, but you would have to implement the interfaces yourself. It seems to be based around a fairly abstract expression-evaluation engine.
Setting up a l.b. project in the IDE does seem to require quite a bit more clicking around than you'd be used to from a traditional VCL app, but that's mostly because there is an additional step involved where you tell the IDE how to bind the gui objects to the data source(s). However, it is quite straightforward to "wire up" live bindings entirely in code if you want to.
I want to run a Delphi application(With forms vcl, forms, etc) using another application with RemObject Pascal Scripter.
will RemObject Pascal Scripter support all the areas of delphi ,
If so can i include 3rd party VCL
If not what can you recommend me to build interpretable applications with forms and controls
will RemObject Pascal Scripter support all the areas of Delphi
Clearly NO. Haven't used it in a while but "all the areas of delphi" is asking allot. Embarcadero itself isn't setting the bar that high with the "Delphi for Mac". Kylix didn't aim for 100% compatibility either.
can i include 3rd party VCL
Any class can be made available to the scripting engine. But the class itself resides on the compiled Delphi side of things, not on the scripted side.
what can you recommend me to build interpretable applications with forms and controls
Take a look at the "mission statement" for the engine:
"Pascal Script is a widely-used set of components for Delphi that makes it easy to add Pascal-based scripting support to your applications, so that they can extend or control your application with custom scripts"
The author's not positioning it as an scripting engine for application development, but as an engine for extending the functionality of applications. None the less you can probably do a lot with it, it all depends on how you define "interpretable application".
Well, yes and no.
Yes in the sense that you can expose pretty much every aspect of your application to the scripting engine.
No in the sense that "all aspects of Delphi" is too vague a definition to begin with.
I think that what you want is to control, through scripting, some third party control in your form. That is pretty much doable and it can be achieved by using the Unit Importer tool.
Now, there is not much documentation but you can get some useful advice in this SO question.
I have a frame in a Delphi 2007 application that I want to embed on a form in a Delphi 2010 application. I have control over both applications, so the interface between them can be anything both versions support. There will have to be some communication between the two. The two approaches I can think of are using CreateParented and messages, or using an ActiveForm. I don't have any experience with creating ActiveX controls or out of process servers, but I've heard Delphi makes it pretty easy.
Is one method better than the other, either in terms of easy of use or ease of development? Are there other alternatives? Any gotchas I should watch out for?
The ActiveX way seems to be simplest if you want to keep your frame a D2007 one but embed it as an already compiled object in a D2010 application.
Is there any difference between using vcl components in Delphi and WinApi functions to create gui application.
#Azad I think there are 2 big differences: the first is the ease of use of the VCL that enables you to drag and drop controls on a form (window), change its properties and assign events, giving you high productivity in the development of the GUI.
The other big difference is the size of the final application, if you create an application using only WINAPI calls, your final application will be smaller than using the VCL.
I recommend you see the project KOL (KOL - Key Objects Library is a set of objects to develop power (but small) 32 bit Windows GUI applications using Delphi but without VCL (or Free Pascal). It is distributed free of charge, with source code.).
(source: kolmck.net)
Almost all real-world Delphi applications use the VCL, and also make OCCASIONAL direct calls to the Win32 API. The VCL framework calls Win32 calls, in the end, anyways. So, you will almost always be using both.
The guy who mentioned KOL is suggesting yet another "middle" layer, because going direct is sublimely painful.
Microsoft has (in historical order), MFC, and ATL for C++, and .NET for the C#/VB.net language, as "framework" layers that live between your application and the raw Win32 API, for their MS Visual Studio products.
People who write anything more complicated than Notepad.exe going straight to the "metal" (Win32 API raw) are rare. So, it's harder, it takes longer to learn, and do everything. And in the end, it's not significantly faster or better. If you really need to be small (like you are writing a virus) maybe you might want to go Win32 native.
The VCL is a complete framework wrapping the Windows API and insulating the developer from the gory details, making it so much easier to develop Delphi applications.
You gain big in productivity and compatibility over Windows version changes...
Well, sure, VCL requires a Borland compiler. The Win32 API works for any language. The point of using a GUI class library, like VCL, is to make the effort of creating a GUI enabled program easier. Doing so using only Win32 is quite punishing.
time, time and then even more time.
You use WinAPI to do things that VCL is not "able" to do.
we'd like to add movable panels to an application. presently we've used DevExpress docking library but have found them to be disappointingly quirky & difficult to work with. it also has some limitations that aren't so great.
auto-hide, pinning, and moving of pages by drag-and-drop are all features we'd like to use.
the built-in delphi docking doesn't seem to be full-featured enough to do the things we need (also see sample below). perhaps i should dig deeper into delphi's docking abilities...my initial impression is that they seem very toolbar-oriented rather than something i can drop a frame into.
i'm not experienced at docking topics. my only experience has been with the DevExpress docking library where i needed to programmatically create & dock panels.
is it my imagination or are DevExpress's products unduly difficult to use/learn? the DevExpress Ribbon Bar component compared to the d2009 Ribbon Bar was certainly a useful experience. i will migrate to the d2009 Ribbon Bar as soon as convenient to do so. it was refreshingly straight-forward to learn and use. a sharp contrast compared to the DevExpress equivalent. if it takes 4x as longer to make it using the DevExpress equivalent, it's time to change direction.
what would you suggest in regard to the docking library?
thank you for your suggestions/comments!
AutomatedDocking
http://www.automatedqa.com/products/aqdocking/index.asp
and for free one JVCL Docking
http://jvcl.delphi-jedi.org/
Disclaimer: I'm not a big fan of docking...but...
Have you played a lot with the docking as it is in Delphi?
If it does all that you want, then give a new try to the VCL...
AutomatedQA's docking components are great. Easy to work with, good help, Visual Studio 2005 style docking hints, etc. I started with DevExpress docking components (I still love DevExpress and use lots of their components), but I think the AutomatedQA docking components are easier to use and more reliable.
LMD Innovative has a docking pack (http://www.lmdinnovative.com/products/vcl/lmddockpack/). Didn't use/need the code so far but the compiled examples worked well.
I'm glad to read your post, I'm using Automated QA' docking components, and I'm fed up with them. I was considering switching to DevExpress, but I think I willl give it a second thought now.
The most problematic with AutomatedQA's component is bugs, sometimes floating windows disappears, when pinned panels are unpinned and stuff like this.
AutomatedQA does not offer a decent support and new releases should not be expected on a yearly basis, even if you have pointed out a bug that can be easily reproduced. I have a suspicion that the docking framework doesn't get much focus within AutomatedQA.
I gues one have to turn to the built in VCL or perhaps JEDI, but I can't find any valuable samples (the mediocre docking sample included with Delphi does not provide much help), but I guess it must be possible, after all they built Delphi using this...
Does anyone know a good JEDI docking sample application?