I know there's an API for creating extensions to Delphi. I use the GExperts package and various JVCL experts frequently. But I've never seen any extensions to the debugger. It would be very nice, for example, to be able to register viewers for various objects instead of having to examine them in the Inspector. (A form with an image control that displays a TImage, for example, or a grid that displays the contents of a dataset.)
Are there any APIs that allow you to extend Delphi's debugger in this way?
EDIT: This wasn't available back when I wrote the question, but Delphi 2010 provides a way to do it.
In ToolsAPI.pas source there is some API interfaces for debugging. You can be informed when a debugging event occurred, info about breakpoints, which process is being debugged etc. with this API. But it seems there is no support for variables or values of them. So there is no easy way to implement your requisition without ugly hacks.
Basic debugger visualizers can be implemented with the Evaluation interfaces exposed by the OTA. (Examples for debugger visualizers can be found here and here.)
A deeper integration into the debugger is possible as well (for example, I wrote a little extension for C++Builder that enables the debugger to evaluate the actual objects behind an interface) - but as Khan pointed out, to achieve such a level of integration, you'll need to resort to quite a few dirty hacks.
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.
Heading : How can I read a StringGrid content in another application's window?
I could get the StringGrid's handle
A Delphi string grid is a pure VCL control. You cannot use windows messages to read its content. You cannot use any of the automation APIs because Embarcadero do not and have never made their controls accessible. For which, incidentally, shame on them.
The only viable way to do this is through gross hacking. If you know the memory layout of the control you can read its memory the same way as a debugger does. Using calls to ReadProcessMemory. However, this will be exceptionally messy and hard to achieve.
A simple approach would be to inject a DLL into the target process. So long as your DLL is built with the same version of Delphi as the target process, there's a reasonable chance that you'll be able to read out the contents of the grid. You can then use IPC to send the information back to the other program.
Note that none of these solutions are remotely appealing. If you can find a cleaner way to do this, possibly avoiding this target process altogether, then you should give it strong consideration.
I've heard a lot about the new/improved RTTI capabilities of Delphi 2010, but I must admit my ignorance...I don't understand it. I know every version of Delphi has supported RTTI...and I know that RTTI (Runtime Type Information) allows me to access type information while my application is running.
But what exactly does that mean? Is Delphi 2010's RTTI support the same thing as reflection in .NET?
Could someone please explain why RTTI is useful? Pretend I'm your pointy haired boss and help me understand why RTTI is cool. How might I use it in a real-world application?
RTTI in Delphi is still not quite as full-featured as Reflection in .NET or other managed languages, because it is operating on compiled code, not an Intermediate Language (bytecode). However, it is a very similar concept, and the new RTTI system in Delphi 2010 brings it a lot closer to reflection, exposing an entire object-oriented API.
Pre-D2010, the RTTI was pretty limited. About the only thing I ever remember doing with it was converting an enumerated type to a string (or vice versa) for use in drop-down lists. I may have used it at one point for control persistence.
With the new RTTI in D2010 you can do a lot more things:
XML Serialization
Attribute-based metadata (TCustomAttribute). Typical use cases would be automatic validation of properties and automated permission checks, two things that you normally have to write a lot of code for.
Adding Active Scripting support (i.e. using the Windows script control)
Building a plug-in system; you could do this before, but there were a lot of headaches. I wasn't able to find a really good example of someone doing this from top to bottom, but all of the necessary functions are available now.
It looks like someone's even trying to implement Spring (DI framework) for Delphi 2010.
So it's definitely very useful, although I'm not sure how well you'd be able to explain it to a PHB; most of its usefulness is probably going to be realized through 3rd-party libraries and frameworks, much the same way it works in the .NET community today - it's rare to see reflection code sitting in the business logic, but a typical app will make use of several reflection-based components like an Object-Relational Mapper or IoC Container.
Have I answered the question?
D2010's extended RTTI is a lot like C#'s reflection. It gives you the ability to get at any field of an object, or inspect its methods. This has all sorts of potential uses. For example, if you can read any field of an object, you can write serialization code that can work with any object. And the ability to inspect methods and obtain their name and signature makes a class much easier to register with a scripting engine.
To me, that's the primary advantage of extended RTTI: The ability to write code that works with any class by examining its members, instead of writing different versions of the same code over and over, tailored to each individual class.
Most people probably won't use it in a real world application.
The people who will use it are the framework builders. Frameworks such as DUnit make extensive use of RTTI.
With the new RTTI capabilities we should expect to start seeing more advanced frameworks and tools appearing, similar to what is available for .NET. These frameworks will revolutionise your development moreso than RTTI will on it's own.
RTTI in Delphi has always been important since version 1.0. Classic RTTI features include the "published" properties section of Classes, which allowed the Object Inspector and the component designtime features to work. For my purposes, I would often use Published class properties to allow for enumeration of those properties at runtime. To store things from my objects to disk, for persistence.
The Delphi 2010 RTTI extends this classic RTTI massively, so much so that you could be forgiven for thinking Delphi did not even have RTTI until delphi 2010.
I would say the #1 most useful applications of "The New RTTI" are (as several other answers already state) going to be in Frameworks written by the gurus, that:
Handle persistence to files or databases. Database and configuration or document saving/loading frameworks and components would use this under the hood.
Handle pickling/marshalling/encoding/decoding to and from various
over-the-wire formats, like JSON, XML, EDI, and other things.
Unit testing was mentioned by someone else (JUnit), but I think perhaps the same frameworks could be really handy for debug and error reporting tools. Given an object passed as a parameter, on the stack, why not have bug reports that can dump all the data that was passed along to a function that failed, and not just a list of functions?
As you can see, some creative people are likely to think of even more uses for this. You could say, that though it does not bring parity to .NET reflection (which another answer speaks more about), it does bring a lot of "dynamic language" features (Think of Perl, Python, JavaScript) to an otherwise strongly typed static-type systems world of Delphi.
For me, personally, extended RTTI gave a possibility to retrieve calling convention from the method pointer. However, currently, that code is under conditional directive, because i am not satisfied with it.
(Critics and suggestions on workarond with basic RTTI are welcome, tho)
Look for TMS Aurelius and you will see that RTTI Attributes are very useful in terms of creating an ORM DataBase Framework and XML Serialization into pure objects and the opposite too.
You are supposed to care because they put it on the box. Clearly they think that some people will care.
Whether you actually have a use for it is entirely dependent on the nature of your projects. Since you didn't have it before and don't understand why having it now is a benefit, this would suggest to me that you don't have a use for it. It's then up to you whether to spend the time researching the subject further in order to discover whether you might be able to find a use for it.
Whether that is the most productive use of your time in relation to your projects, again is something only you can know.
I'm working on Windows XP/Delphi 7. I need to add some procedures (or functions) inside a program that is running, and I do not want to re-compile it once again after I finished it.
I just have a host application with 5 functions to send different types of alarms, but there are other new alarm types, so I have to do new functions to send those alarms, but I should not re-build the host application. I have a class named TAlarmManager that it's invoked calling those functions.
Maybe a plugin?? OK, but how can I "insert" new functions??? Tutorial, manual, book, etc.. for learning about this, or any advice on how to do this???
I have studied plugins (I'm totally new on this theme), but no one "talks" about adding functions to a host application. It seems to me that plugins add functionality from itself, I mean, they have been developed with self code to do something, not to "add" code to the host application... How can I do this??
For the technical side: How does the Delphi IDE do it? That would be the first place for me to look.
To understand plugins, you must understand that you can't add new functions. You could but since the old code doesn't know how to call it, they wouldn't be called.
So what you do is you add a "register" or "start" function to your plugin. That start function gets a data structure as parameter which it can examine or extend. In your case, that would be the list of alarms. Alarms always work the same (my guess), so it can add additional alarms.
The main code will then, after registering all plugins, just walk over the list of alarms and invoke the standard alarm function on each of them. It no longer cares where each alarm comes from and what it really does.
The key here: You need to define an interface which both sides subscribe to. The main code calls the interface functions and your plugin code implements them.
Another option available is to use a scripting component to your project. One which works quite well is PascalScript. This would allow you to load external scripts after the fact and then run them as needed to interact with your application. As Aaron suggested you will also need to still provide an interface of some sort for your script to interact with your application.
See also Plugins system for Delphi application - bpl vs dll? here on Stackoverflow.
I'm not quite sure what you mean by "alarms", so I'm making a couple of assumptions.
1) If you don't need additional code for the alarms, I would try to make them data driven. Keep the different kinds of alarms in a database or configuration file, which makes it easy to update applications in the field without recompiling or reinstalling.
2) If you need special code for each alarm, you could use run time packages as plug-ins for your application. Search for Delphi runtime packages to get some ideas and tutorials. Here are a couple of links I found:
http://delphi.wikia.com/wiki/Creating_Packages
http://delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm
3) Scripting, as skamradt already mentioned. If it makes sense for your application, this could also let your customers write their own add-on functionality without requiring a recompile on your part.
You almost definitely want to use Pascalscript, as skamradt suggests. You should start here, and seriously consider this option. There are many possibilities that come out of being able to serialize live code as text. The only downside is possibly speed of execution, but that may not matter for your application domain. I would have upvoted skamradt, but I don't have enough reputation to upvote :)
Some time ago I was looking at a situation sort of like what you're describing.
My answer was .DLLs. I put the variable code in a .DLL that was dynamically loaded, the name specified in a configuration file. I passed in a record containing everything I knew about the situation.
In my case there was only a success/fail return and no screen output, this worked quite well. (It was commanding a piece of machinery.)
This sounds like a place where a scripting language or "Domain Specific Language" may make sense. There are several approaches to this:
Implement alarm functions in VBscript (.vbs files written in notepad) that accesses your Delphi code via COM API. Using the COM API gives you access to a large range of programming tools for writing functions, including Delphi. This is the most clumsy solution, but easiest to do. It may also be a benefit to your sales process, and it is always good to think about how to sell things.
Implement your own function language in Delphi. This way you can make it so easy, that your endusers can write their own alarm functions. If you do it as an expression evaluator, you can write an alarm as 2*T1>T2. There are several expression evaluators out there, and you can also write your own if they don't match your needs.
Use a predefined programming language inside your Delphi application, for instance, "Pascal Script", see http://www.remobjects.com/ps.aspx
You should take a look at PaxCompiler, like PascalScript it allows to load scripts, but you can even precompile them before for more performance. Look at the demos section for the solution of your problem.
As a side note, the web page really looks bad, but the package is really powerful and stable.
I think that the scripting solution it's good for this situation.
There are many scripting packages that you can evaluate:
Context Scripting Suite
Fast Script
RemObjects Pascal Script
TMS Scripter Studio
paxScript
Other packages that you can find on Torry, DSP, VClComponents,...
Regards.
I need a few of my related applications to communicate to each other (exchange data and initiate actions). Requirements are without packages and no sockets. So I guess that leaves named pipes, WM_CopyData (like Skype does it) and command parameters. What are your best practices?
You probably have a couple of options.
Beyond what you already have:
DDE
Memory Mapped Files (MMF)
MailSlots
I would probably go with either the Pipes or the MMF.
There are a couple of free MMF components that you can download,
Deborah Pate has a set of freeware classes you can use.
MapFiles.zip
Check for MailSlots on Torry's site.
The final solution might be dependent on the amount, size and frequency of the data transfers that decide which option you choose.
I would advise to use COM in this situation. (Attention: not COM+, not ActiveX, not OLE; COM, just COM.)
Since Delphi 7 (or an earlier version, I'm not sure), this is easily done by adding a Type Library to the project, and an Automation object.
Advantages are it's pretty widely supported, both within Delphi (the Type Library Editor has everything you need and updates your code, and COM internals and registering are catered for from the ComServ unit), and outside of Delphi (I use it in a number of project to interact with all sorts of applications: C++ projects, Word and Excel documents using VBA, oldskool ASP...).
An only disadvantage I encountered may be threading issues, in normal applications, a plain CoInitialize(nil); at application startup will do, in more complex applications, you need to think about 'threading apartments' or use free threading and do your own locking. (Which in some cases you've been doing already.)
Another alternative which is dirt simple to implement is to use the database to pass information.
Not overly elegant, and it does use a lot of overhead, but if your application is already data-aware (ie has a database as part of it), then using a table or two to pass information is pretty easy.
You could use simple files: One side writes to it, the other reads. If you need two way communication, just use two files, one for each direction.
Of course this is not really high performance.
Another vote from me for named pipes, for the data exchange. I like them slightly more than mmap files, since the win32 pipe APIs give you some nice choices out of the box: sync/async, byte stream vs message packets, simple ReadFile/WriteFile calls. All of which you could do yourself with mmaps... but pipes are already there...
And you can control access with security attributes -- which isn't an option with WM_CopyData. This might not be an issue immediately... but can be handy to have the option, even if you don't care who sends your app messages. For me, this was helpful when Vista came along, and suddenly user apps ran in a separate session to my service. Was good that tweaking the security attributes was the only thing needed to get things working again.
For "initiating actions", you might be able to get away with something as easy as some named Events, and not worry about sending messages at all? The interested parties simply wait for it to be signalled.
Personally, I'd avoid COM unless you have to specifically support COM-based clients.
Do not use COM, too much overhead (variants) and you must register you .dll or .exe (and it gives a lot of weird installation + update problems).
I should go for MMF, I use this for communication with Windows Services.
I use the following TGpMessageQueueReader and writer for this:
http://17slon.com/gp/gp/gpsync.htm
If you want to pass data, call functions etc then use COM, however if there are lots of calls be aware that COM is slow. Also you might have to register the application with "xxx.exe /Regserver", before it will work.
Is'nt this the sort of this that RemObjects is good at?
Bri