I am facing an issue while recognizing Delphi Objects using UFT.
I have even checked the Delphi plugin while recognizing the objects but every time it is showing a Window's type Object. Below is the screenshot for the same.
Please suggest some solution for this.
Thanks in advance.
To use Delphi add-in, you MUST have access to source code of application - to be able to re-compile it with QTP integration (and possibly with Delphi extensibility) units. You can't use Delphi add-in with your application out-of-the-box, without re-compiling it. Please, refer to Delphi add-in help in UFT.
Related
For a library I am working on, I have created a help file (Help 2 format). It would be very convenient if the other developpers of my team that use the library, could search the help from inside the Delphi IDE.
Is it possible to make Delphi XE2 search in a custom help file when I press F1 in the Delphi IDE? And if so, how should I do that?
Yes, it is, the same way third-party component vendors do. As you say, use the free Microsoft Help 2 compiler, Help 2 Workshop, available through MS.
Once you've written and compiled your help, you incorporate it into the IDE's help system via H2Reg.exe, which you can find in your $(BDSDIR)\Help\Doc folder. Read the comments in h2reg.ini (in that same folder) for details regarding how to do so.
There is a whole host of components that I am trying out to better understand how to detect when a file or folder has changed. I want to write a delphi application to also do this but delphi Unicode(Tiburon) doesn't seem to ship with any component that can accomplish this. At least not anymore. I found a curious component on the palette called shellersources and after just placing it on a form and running it I get an error:
Cmctrls was compiled with a different version of SHLObj.IAutocomplete
I tried virtually all the component listed here: shell resourcehttp://www.torry.net/pages.php?id=252 and interestingly I get the same exact error on compiling them. I am running delphi on Vista, could this be a vista issue? I also tried the SHChangeNotify component from about.com and even it too produced an identical error concerning SHlObj.IAutocomplete. Anyone noticed this? Strange.
There are two Windows API calls that will help you accomplish this in Delphi:
FindFirstChangeNotification
FindNextChangeNotification
The drawback is that these function calls are low-level-non-delphi components. But you can still make those function calls in Delphi. If you ABSOLUTELY need a delphi component, you could always write your own, using the mentioned functions as base.
HI,
I want to write a small Delphi IDE Expert for D2007-D2009 (aka. Galileo IDE) in order to show a window with a TMemo instance on it, with all the component names and classes from the form designer in the above memo. The selected component will be marked with a '*'. The expert should appear on a menu/toolbar and have a shortcut assigned.
How do I do?
Ps: Actually the real code is more complicated than that, but I want to have a general framework to get started.
TIA
I did my first OTA with help of these links:
Erik's Open Tools API FAQ and Resources (The author of GExpert)
Delphi Open Tools API from Jim Kueneman - Mustangpeak
Delphi Open Tools API from RayRay Lischner
They are not updated to the latest versions, but they will you good start point and most of the code will work with the last version, I tried them with D2007.
There are links to articles describing how to write an OTA plug-in here:
http://delphi.about.com/od/objectpascalide/a/wizardsexperts.htm
A vendor has developed an ActiveX control in Microsoft C++. The ActiveX worked fine when they were using the 16bit version of the compiler. The control does not work when compiled using the 32bit version within the Delphi2007/D7 environments. If you drop a control on a form and run it throws an "Floating Point Error".
It is a Delphi issue. We are able to use the ActiveX in other applications.
Anyone ever have a similar problem or have a solution for this?
Sounds like an FPU problem - check out Set8087CW in Delphi's help file.
In my application, originally built with Delphi 7, I use the SPHelpIntegration code to enable CHM help via the F1 interface. I figured that this wasn't needed in Delphi 2007, so I removed the units and built my app. I then press F1 and get a message that no help interface is installed. The online help doesn't tell me a lot about what is needed to make F1 help work. Do I have to include a unit or something? Or should I just carry on doing what works?
Add HTMLHelpViewer to your uses clause to handle CHM files. There is an issue in using them is they must exist on the local system (not a network share) to view properly. There is a registry hack to change this behavior, but I have found it easier to just install the help files locally on the system.
Lately rather than CHM files, I used the Adobe OpenPDFParameters API calling conventions to throw them directly into my PDF version of my printed manual jumping to the section based on the current form (I grab the form class name and use it in my named sections). It requires that the workstation has a PDF reader, but who doesn't now days?
Yes, you need to include a help viewer in the uses clause.