i have an OLE automation server (in fact, Open Office Calc) that doesn't close - delphi

I have an OLE automation server (in fact, Open Office Calc) that doesn't close. Is there a way I can see what OLE objects are not freed? Truly, I think that because all the variables for this either go out of scope or are set to Unassigned, I shouldn't be having such a problem. as a precaution, I even set the ones (that I found) that go out of scope to Unassigned.
I have been careful to close Open Office Calc in the way prescribed by an example for this.
This might be somehow related to the presence of (embedded) pictures I've been adding to the Office document.
How can I find the cause of this?
I think this is now solved. I found that something about how pictures were being inserted was a "problem". I don't have a complete understanding of why it was a problem but it's enough that it works.

You probably need to display some example source in order to determine the problems you are having. However, you may also want to check out some example Delphi code found online to help accessing Open Office via Delphi: http://www.oooforum.org/forum/viewtopic.phtml?t=8878

Related

Bug in Grid Component becuase role ="treegrid"?

The element has ARIA role="treegrid" despite it functionally being an element that should have the ARIA role="grid". Go to the Vaadin Grid component page and inspect the first table in the Accessibility tab. It has role="treegrid".
From my understanding, this is the wrong role, because the rows can not be expanded in this Component.
See treegrid role on MDN.
The correct role should be "grid", just like the name of the Component.
See MDN grid role
Am I understanding this correctly? Shouldn't the role be grid?
Note: I am an accessibility tester with no access to the source code, I found this using dev tools while inspecting my colleagues work and the Vaadin docs. This means I do not know if this is an error in the documentation and my colleagues just made the exact same error or if this is a bug in the framework.
Good catch, and yes, you are understanding this correctly.
To cite the related bug report:
...it may prove to be confusing to screen reader users. While they will never be able to expand the tree that contains only 1 level of data, they will still hear "Level one" announced which is suggestive of there being more levels. Without being able to see the table, it is not unlikely that a screen reader user would assume that there is more content that they cannot access but without know why. It's not the biggest problem, but it adds an element of uncertainty.
What to do if you discover an error like this
1. check if the issue is known
In Open Source libraries like Vaadin, you can go to their issue tracker and search if the issue is known. Often, these are GitHub or Gitlab pages, and you usually find a link on the library’s public page in the header or the footer.
For example, this is an issue already known by their developers: Grid uses treegrid role even when populated with only 1 level of data #4318
As you can see, these components often are able to cover much more complex scenarios, so the Grid component is capable of becoming a real tree grid, but in the configuration used in your project it’s not.
2. Create a bug report if it’s not known yet
If you cannot find anything, go ahead and file a bug report.
Usually, you’d also find some guidelines on how to do that.
3. Fix the issue in code
As I find myself repeatedly pointing out recently: There is no point in trying to fix accessibility issues from the outside of a library. It’s often a hack, therefore fragile, inefficient, and only your project profits from it.
Instead, if you have developing force, go and fix the issue at the source, if it is important to your project. This is how Open Source works in a nutshell: Somebody, for whom the issue is critical, provides a fix for everyone.
For example, the Vaadin Contribution Guide explains how to go about this.

Print ClientDataSet without consultation with the reporting component

Preferably FastReport, but can be any that you know. I just ZConnection and ZQuery to work with the database. When I need to feed a grid with data from the database, do the power on hand, without using ClientDataSet. Does anyone know how I could feed a report without turning it into components database?
FastReport supports a wide variety of databases and datasources. You don't need to connect it to a TClientDataset to use it. From the wording of your question, it sounds like you need to make use of the TfrxUserDataset. This allows you to drive a report from any source (Listview, StringGrid, ObjectList etc).
You provide data via TfrxUserDataset's OnGetFieldValue event. You will also need to provide a RecordCount value and a OnCheckEOF event. As TLama pointed out, there are demonstration programs on how to do this in FastReport's Demos folder.

How to show relationships in my application?

I'm developing my MS Access database editor (mdb, accdb) which I will give everyone for free. I've done mostly everything that matters except relationships. The problem for me is how to show relationship(s). I would like to do it like in the real MS Access:
The thing is, I don't know how would I connect these child windows with a line that is stretching and resizing when one of the windows move etc...
This maybe not a question that can have a direct answer but I'm stuck here and don't know how to show those relationship(s). I'm using C++ Builder XE2.
So you need a library to draw graphs...
Making an answer, for being able to put links in the list (which comments would not allow)
http://sourceforge.net/projects/extgraph/
How to create graphs in Delphi application
http://www.torry.net/pages.php?s=88

How to get the property list and values of a control within a third-party Delphi application?

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.

Setting up help for a Delphi app

What's the best way to set up help (specifically HTML Help) for a Delphi application? I can see several options, all of which has disadvantages. Specifically:
I could set HelpContext in the forms designer wherever appropriate, but then I'm stuck having to track numbers instead of symbolic constants.
I could set HelpContext programmatically. Then I can use symbolic constants, but I'd have more code to keep up with, and I couldn't easily check the text DFMs to see which forms still need help.
I could set HelpKeyword, but since that does a keyword lookup (like Application.HelpKeyword) rather than a topic jump (like Application.HelpJump), I'd have to make sure that each of my help pages has a unique, non-changing, top-level keyword; this seems like extra work. (And there are HelpKeyword-related VCL bugs like this and this.)
I could set HelpKeyword, set an Application.OnHelp handler to convert HelpKeyword requests to HelpJump requests so that I can assign help by topic ID instead of keyword lookup, and add code such as my own help viewer (based on HelpScribble's code) that fixes the VCL bugs and lets HelpJump work with anchors. By this point, though, I feel like I'm working against the VCL rather than with it.
Which approach did you choose for your app?
When I first started researching how to do this several years ago, I first got the "All About help files in Borland Delphi" tutorial from: http://www.ec-software.com/support_tutorials.html
In that document, the section "Preparing a help file for context sensitive help" (which in my version of the document starts on page 28). It describes a nice numbering scheme you can use to organize your numbers into sections, e.g. Starting with 100000 for your main form and continuing with 101000 or 110000 for each secondary form, etc.
But then I wanted to use descriptive string IDs instead of numbers for my Help topics. I started using THelpRouter, which is part of EC Software's free Help Suite at: http://www.ec-software.com/downloads_delphi.html
But then I settled on a Help tool that supported string ID's directly for topics (I use Dr. Explain: http://www.drexplain.com/) so now I simply use HelpJump, e.g.:
Application.HelpJump('UGQuickStart');
I hope that helps.
We use symbolic constants. Yes, it is a bit more work, but it pays off. Especially because some of our dialogs are dynamically built and sometimes require different help IDs.
I create the help file, which gets the help topic ID, and then go around the forms and set their HelpContext values to them. Since the level of maintenance needed is very low - the form is unlikely to change help file context unless something major happens - this works just fine.
We use Help&Manual - its a wonderful tool, outputting almost any format of stuff you could want, doc, rtf, html, pdf - all from the same source. It will even read in (or paste from rtf (eg MSWord). It uses topic ID's (strings) which I just keep a list of and I manually put each one into a form (or class) as it suits me. Sounds difficult but trust me you'll spend far longer hating the wrong authouring tool. I spent years finding it!
Brian

Resources