In Delphi; what are the differences between Application.MessageBox, Windows.MessageBox or Dialogs.MessageDlg?
Or which is more efficient to use computer memory?
Windows.MessageBox is the WinAPI MessageBox, Application.MessageBox is a wrapper around it. Dialogs.MessageDlg however is a VCL form. So if you are concerned about memory or thread safety, the first two might be better suited. MessageDlg OTOH is more flexible and easier to use (IMHO, of course).
Nowadays, I'd consider task dialogs (TaskDialogIndirect, TTaskDialog or another wrapper).
Windows MessageBox is localized by OS (Yes, No, Cancel...), MessageDlg can be localized by hand.
If I remember correctly, there is one important distinction bewteen the Delphi VCL message boxes and the Windows ones - you can specifiy flags that stop the Application messages from being serviced (eg MB_SYSTEMMODAL). This can be useful for displaying errors where you need to 'freeze' your application - the Delphi MessageDlg will still fire timer events even whilst on screen. See:
MSDN MessageBox stuff
Memory usage shouldn't be such a problem with message boxes. I personally prefer the VCL form (Dialogs.MessageBox) since I can localize it from the Consts.pas unit. I also like it from the fact that I can add custom controls to it, like checkboxes for "don't show this again" and other stuff like this.
Why do you care about the tiny amount of memory used by a message box? There are many other things you should be concerning yourself with when writing a Delphi app. In any case, as far as I'm aware these are all thin wrappers around the Windows MessageBox API.
They all do the same - invoke WinAPI function MessageBox(). The difference in resource consumption if any is minimal. If you care so much you can call MessageBox() directly - just include "uses Windows".
Related
I have an application using TNotebook to switch between different sub pages, that are shown.
Now I have to extend this code a little bit (namely add a page and change sizes).
I was told that TNotebook shouldn't be used anymore. In Delphi's help I find "New applications should use TPageControl".
My question: Should I refactor the code to use TPageControl instead of TNotebook? What are the disadvandtages of TNotebook?
The main advantage of TPageControl, in my opinion, is that it is a system native control, unlike TNotebook. When you use system native controls, the control is painted by the system, and so takes on the look and appearance that is native to the operating system that you use.
When the application is run on a new version of the OS, your control automatically gets the appearance that is native to that OS. What's more, the behaviour is system native. By that I mean the way the control responds to keyboard input and so on. That's less of an issue with TPageControl since the system does not provide that much default behaviour. But as a general rule the advice is sound.
When none of the system native controls meet your specific requirements, you may need to use a non-native control. And then you have to work to make sure that your control adapts to its surroundings. But when there is a system native control, unless there is a strong reason to avoid it, you should use it.
Another disadvantage of TNotebook is that it excludes the form or frame on which it is placed from inheritance.
I have a piece of software written in C++ Builder 6 (yes, I know that it's terribly outdated and I'm not going to rewrite it). It does heavy number crunching which takes a few minutes to complete. I want interface to be responsive during these computations. I remember there was an extremely simple solution for this problem in Delphi - calling a special method of form/app, but I can't remember what was it. Any suggestions?
Application.ProcessMessages(); but it has dark side.
In Delphi, that's Application.Processmessages(). Be aware thought that calling that methode has some side effects, like described here.
You know you have to do it, Andrew. You know you have to do the number crunching in a separate thread. Now go and implement it.
You could modify the program to do all of the number crunching in a background thread which will not lock up your GUI. More complicated than the other answers here, but it is an option open to you.
I'd like to get information about a third party application's controls such as a list of its properties and their values: something like RTTI information but for a third-party Delphi application.
I see that this is possible. For example TestComplete has the ObjectSpy window which can give many useful information about the control, including RTTI information. How can this be done ?
Edit: To explain why I'm investigating this issue... I'm a registered user of TestComplete/TestExecute and I do like... most of it. I can get over the minor things but the one major problem for me is their license verification system which requires me to have a physical computer (not a virtual machine) always on just for the sake of running a license server so that TestExecute can run at night. As I have basic testing needs (compare screenshots and check basic Delphi component's properties) I wondered how hard it would be to make my own private very simple "TestExecute-like" application.
To go further, I suggest you these relevant resources found here on SO
Writing a very basic debugger (The accepted answer along with its comment thread are all valuable).
Is it possible to access memory from an application to another ? How? (Excerpt from the accepted answer: It is possible. Just use the Windows API functions WriteProcessMemory/ReadProcessMemory. Pass in the handle of the process and the pointer to the data).
Search the memory of another process (The excellent accepted answer also forwards to another valuable resource delphi-code-coverage by Christer Fahlgren and Nick Ring).
StackWalk of other process in delphi? (Check Barry Kelly's answer !!!, the same for the one from the AsmProfiler author !!!).
I strongly suggest you to port to Delphi this c++ project entitled Get Process Info with NtQueryInformationProcess: A hands on experience on using ReadProcessMemory to access the CommandLine used to launch another process.
Last Edit:
NtQuerySystemInformation Delphi Example.
RRUZ's answer to Delphi - get what files are opened by an application as suggested by LU RD.
When we want to take another application which is compiled with debug information and get stuff out of it at runtime, what we are dealing with is the problem of "how to write my own custom debugger/profiler/automated-test kernel".
TestComplete and other AutomatedQA programs contain a Debugger and Profiler Kernel which can start up, run and remotely control apps, and parse their Debug information in several formats, including the TurboDebugger TD32 information attached to these executables. Their profiling kernel also can see each object as it is created, and can iterate the RTTI-like debug information to determine that an object that was created is of a particular class type, and then see what properties exist in that object.
Now, TestComplete adds on top of the AQTime-level of stuff, the ability to introspect Window handles, and intuit from Window Handles, the Delphi class Names that are behind it. However, it's much easier for you (or me) to write a program which can tell you that the mouse is over a window handle that belongs to a TPanel, than to know which version of Delphi created that particular executable, what version of TPanel that is, then, and what properties it would contain, and to read those values back from a running program, which requires that you implement your own "debugger engine". I am not aware of any open source applications that you could even use to get a start writing your own debugger, and you certainly can't use the ones that are inside AQTime/TestComplete, or the one inside Delphi itself, in your own apps.
I could not write you a sample program to do this, but even if I could, it would require a lot of third-party library support. To see the window classes for a window handle which your mouse is over, look for how to implement something like the MS Spy++ utility.
An easy case is if your mouse is mousing over a window inside your own application. For that, see this about.com link, which simply uses RTTI.
I have an Stock program which developed by Delphi, I want a tools which can read the data from the stock program, for example, the stock price in Delphi grid object.
The Stock program under test is close source, so no chance modify source code which QTP/Robot inspector required. I cannot tell out which Delphi version it is using, neither the object is a standard delphi control.
So anyone can tell out is it possible to inspect that delphi program object data through other technology ?
thanks in advance.
You can use a tool like Winsight to find out the structure of the program window, and use FindWindow and EnumerateChildWindows to find the controls. Then you can use GetWindowText api to get the text of the control. This will work with most controls, but might not work for all. For instance TLabel control has no handle, but does its drawing itself. It has not handle to get the text from and it won't show up in WinSight. You'll have to OCR the window to get those label texts. :p
But this 'testing' sounds more like 'hacking' or 'controlling' to me, if you don't even know what kind of controls are used and which version of Delphi is used, why are you the one testing this program this way?
Trying to read data out of a Delphi grid control is not going to work out for you. It's not like a standard Windows edit control which you could just call GetWindowText on.
If you really want to get the information from this existing program then you'd need to poke at its internal memory or do an OCR on a screen grab. All pretty horrible to contemplate.
I am looking to build my own component and have no idea where to begin. I have some Delphi books but they are old and outdated, and am looking for some recommendations on tutorials/books to help me do this. The component will be pretty simple, basically 2 labels and an image. I need hundreds of these in an array, so I thought a component would be the best route. The text will adjust based on width etc, and have some mouseover events. So basically, where do I begin?
I am using Delphi 2009, this will be a win32 app.
Thanks!
You can order Ray Konopka's book Dev. Custom Delphi 3 Components - PDF for 25$. It's a specialized book on the subject and very good for a beginner too.
The main principles behind developing components is:
Whether the component is visual or
not (Does it need a Canvas to paint on)
Does it need a window handle or not (visual or non-visual)
Once you answered those questions you can look at Delphi's source code for examples.
As far as I know, Delphi Component Design, by Danny Thorpe, is still the best book on the subject. Component design hasn't changed significantly in the last 15 years, so whatever books you have probably aren't as outdated as you think. There are three things to keep in mind while reading older references:
Names of certain units have changed. There's no DsgnIDE anymore, for example. It's DesignIDE instead.
Design-time code is strictly separated from run-time code now. This means you can't use DesignIDE in your component's unit, or else you're barred from using run-time packages. Older Delphi versions didn't have this technical restriction (although it's always been a legal restriction), so old code examples you find might need to change a little bit.
Strings are Unicode now, so as with all old code examples you find, there might be some invalid assumptions about character sizes that you'll need to recognize.
The biggest obstacle to writing components is that you're expected to use various protected members of the classes you descend from, but those frequently aren't documented, so you'll have to be much more willing to go read the VCL source code for examples of how various methods are used.
The easiest way to do what you want is to create a new form. Drop the labels and image and arrange them the way you want; if it suits your need, put them on a panel so they can be moved around as a unit.
Select all the components you want included (and including the panel if you chose to use one), and then click the Component item on the IDE's main menu, and select the "Create Component Template". (It's only enabled if you have selected components on the current form.) A dialog will appear asking you for a name for the new component, and the Component Palette page on which you want it to appear.
Take a look at this article, which describes how to build new components made up of a group of existing components.
Don't worry about your books being old.
Just about everything from the old days still works fine and what little doesn't is generally due to name conflicts or the addition of Unicode in the 2009 version.
They aren't Microsoft, they don't go breaking old code without good reason. In fact, take some code from the old DOS days--assuming it doesn't try to manipulate the screen it's likely to run with minimal fixup.
Don't worry about your old books! Since v3, Delphi hasn't changed much. This is why most of the programs compiled with D3 still compiles in D7 or even newer versions. And if it doesn't compile, probably you need to change a line or two, here and then.
I would recommend you to search other VERY simple components on Internet and see how they are made. Then make your own and post it here. Let other take a look at it and suggest improvements or spot bugs.
About your control's design:
1) maybe you DON'T need those two labels. You can just paint the text directly on the image. If you have lots of those components as you say, you may save a little bit of memory.
2) you may NOT want to have lots and lots and lots of images loading in one form. The overhead may be significant. What you can do is to load the pictures ONLY in images that are visible on screen - and you will put on screen ONLY 5-10 images (or whatever number of images you can show on the form without going out of screen). As the user scrolls down, you keep the same same TImage controls on screen but you load new (next) images in them.
3) You may not want to store labels and TImage in an array (I suppose it is an TImage because it seems you want to show them on the screen else you won't need labels - you need to explain your problem in more details if I got it wrong). But you can store a TBitmap and the text (that you want to display in labels) instead.
So, you may need to calculate how much CPU/disk overhead your hundreds of controls will create and how much memory they need. If you stay well under 1GB and the loading time is under 10 seconds, then it is relatively ok. IF not, you may want to think about your control's design before starting to actually implement it.
Hope this was helpful.
See ya.