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.
Related
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.
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.
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.
Does anyone know any good library (free or commercial) for Delphi that can read/parse/modify MS Word documents (preferably with Word 2007 support) without MS Word OLE Automation? I've found some for .Net, but none for Delphi.
For example, here are two .Net/Java libraries - Aspose, Word.net
I don't want to add .Net dependencies in my application. A library that compiles right inside the exe will be most preferable, but any ActiveX will also work.
Thank you.
I know (a simple non-commercial) variant for Excel, but not for Word. And not for very new ones.
DR: the problem is that that needs Word installed. The options above don't. Moreover OLE can get slow, e.g. when you want to make umpteen personal letters for a mailing in it.
The only other routine I can imagine is automating Open Office. But that has the same speed problems (or worse) probably, so that would depend on why you exactly want this.
The Office format is horribly complicated, and nearly every solution will be more expensive (in either vast time or money) than just coughing up a copy of word. (and with OOo you could even avoid that)
Scalabium has TSMWordDocument component that can extract the plain text and is entirely in native code. It doesn't support modifying them or extracting graphics/styles though. Their SM Export component set allows generating Word documents, but I don't think it supports reading them. We use the TSMWordDocument one and it's ridiculously fast compared to COM automation. The only downside we've hit is that it even though it's Delphi 2009 compatible, it still doesn't handle international text unless the system codepage matches (so Japanese on a Japanese system is ok, but not on an English one).
You could use the .NET library and create an ActiveX/COM wrapper for it, which you can use from Delphi.
This article describes the interop possibilities between COM and .NET. Look at "Using .NET Objects from COM"
Microsoft's formats are so complex that it is a lot of work to write, and keep up to date, a set of components to do what you want without automation.
There is Winsoft's Office Component Suite, but you'll see that hasn't been updated to work with the latest version of Office, or with Delphi 2009+.