Mark Williams

I did try that, but still couldn't find it any reference to it. Yes. Sorry. Tired and brain functioning slower than usual snail pace. I have discovered that today. Because the because the compiler didn't recognise the unquoted reference to Shell32 I thought that the functions must have been re-packaged differently for 64 bit somehow (Shell64 or some such) . Anyway simply putting quote marks round Shell32 in my old function code worked fine. Live and learn.

Possibly, however it worked a treat in this case and helped me an identify the problem. Please see my last post. As for the code I have posted it earlier (see a few posts back) and note Fred's comments as to UnCoinitialize.

BTW I meant to mention that you would probably have got a faster reply to this question if you had posted it in the FireDac sub-forum in Databases.

You need a datasource that points to the master dataset. The Detail dataset needs to have its Mastersource property pointing to the dataSource (this step needs to be followed for both of the options specified below). You can then either: use the object inspector for the Detail dataset to define the relationship with the Master table (you need to set IndexFieldNames, MasterFields and as already mentioned MasterSource) or if the Detail dataset is an FDQuery you can define the relationship via a parameterized query entered into the SQL.Text property eg "SELECT [fields] FROM [mytable] WHERE [detail_table_foreign_key] = :[master_table_primary_key So in the latter case, if you had a master table called "employers" with aprimary key called "e_id" and a detail table called "employees" with a foreign key called "employer_id" your Detail query would need to be as follows: SELECT * FROM employees WHERE employer_id = :e_id The parameter is case sensitive. It must match precisely the name of the primary key field in the Master table.

I found the code online some years ago. Hadn't noticed the failure to CoUninitialize. Thanks. I managed to get my old code to compile this evening by enclosing Shell32 in single quotes. I didn't realise that an error message would be generated if ILCreateFromPath returned nil. Thanks also for that suggestion. I can now see why my code was doing nothing. Unfortunately, the reason was rather embarrassing. for test purposes, I had hard coded the file path rather than use a dialog and as a result I was submitting a non-existent file! However, without your suggestion re GetLastError I would never have realised that (at least not for another few years).

Sorry. I mistakenly thought Shell32 was restricted to 32 bit and that I was looking another function. I will know better in future (hopefully). Delphi 10.3 update 1. Latest However see response to your last message.

It's pretty much the same as mentioned in the link above. However: //Following is to enable opening of a folder and selecting of file const OFASI_EDIT = $0001; OFASI_OPENDESKTOP = $0002; {$IFDEF UNICODE} function ILCreateFromPath(pszPath: PChar): PItemIDList stdcall; external shell32 name 'ILCreateFromPathW'; {$ELSE} function ILCreateFromPath(pszPath: PChar): PItemIDList stdcall; external shell32 name 'ILCreateFromPathA'; {$ENDIF} procedure ILFree(pidl: PItemIDList) stdcall; external shell32; function SHOpenFolderAndSelectItems(pidlFolder: PItemIDList; cidl: Cardinal; apidl: pointer; dwFlags: DWORD): HRESULT; stdcall; external shell32; function OpenFolderAndSelectFile(const FileName: string): boolean; var IIDL: PItemIDList; begin result := false; CoInitialize(Nil); IIDL := ILCreateFromPath(PChar(FileName)); if IIDL <> nil then try result := SHOpenFolderAndSelectItems(IIDL, 0, nil, 0) = S_OK; finally ILFree(IIDL); CoUninitialize; end; end; This works fine in older version of Delphi and 32bit apps. It doesn't compile on 64 bit platform. I noted that Remy enclosed his references to Shell32 in single quotes. I have done the same and it now compiles. However, it doesn't work. Doesn't throw up any errors it just doesn't do anything. It fails to create a PItemIDList on the call to ILCreateFromPath. I have read on the Microsoft forums (MS Forum) that this may be a bug with Windows 10 64 bit only. @FredS mentions above that he has it working in Berlin and 64 bit. He doesn't mention if that is on Windows 10 or not.

I've tried that. I can't find which unit declares PCUITEMID_CHILD_ARRAY and my debugger is also unhappy with the reference to 'shell32'. Can Shell32 be referenced in 64 bit apps?

I had it working in 32 bit using very similar code to that in the forum message which Dave Nottage has linked above. I can't get it to work in 64 bit. The references to "Shell32" throw up unrecognised errors and I am not sure what to replace them with. Have had a look at the Windows documentation and it says its a Shell32 function. Can you explain what you did to get it to work in 64bit please?

His opening words are I can't see any reference in the rest of the post to 64 bit.

I am looking for a way to kill a hung thread, no questions asked! I've tried to find an answer to this on the web, but the replies are usually "that's really bad dude, debug your code" which I would say is sound advice. However, I am using OLE to open MS Powerpoint to convert to Powerpoint docs to pdf. This needs to be done in (sometimes large) batches along with many other conversion routines for other types of files. The problem is that if you try and open a password protected Powerpoint the process simply hangs, nothing you can do about it. Word is fine. You just feed it a fake password and it excepts if the password is wrong. Unfortunately, Powerpoint doesn't allow you to do that unless you use it's ProtectedWindowView. This will raise an exception if a password is needed. However, there are two problems with it: It is only available for 2010 onwards (minor issue) It's really clunky as it visibly opens Powerpoint and there is no way of stopping it doing that as far as I can see (deal breaker for me). So my idea was to deal with each Powerpoint document in a separate thread. If after a period of time the thread doesn't terminate I can assume it has hung due to password issues, but then I need some way of killing it.

Uhm... Are you sure? You said above it couldn't be killed. However, if it works it would solve the problem. I would only be killing the thread in circumstances where the thread had been cause to hung by MS Office. I may just go with the clunky solution I referred to in original post and only allow Office to try and open powerpoint where Office 2010 is installed.

Hadn't thought of a separate process. That's an excellent idea. Thanks

I am trying to load a TFDQuery from a memory stream using the default format. I can do this fine from file: Query.LoadFromFile('c:\data.DAT', sfAuto); If I load the same first into a stream and then call LoadFromStream I get error code 710 "Invalid Binary Storage Format". I have the DefaultStoreExt of the ResourceOptions for the Query's connection component set to ".DAT" and its DefaultStoreFormat to sfAuto. Is there anything else I should be doing? NB I have also tried setting the DefaultStoreExt without the lading period.

have found cause of problem. Had to do with something else. Please ignore.

I create an instance of Word using TWordApplication: WordApp := TWordApplication.Create(frmWord); WordApp.ConnectKind := ckNewInstance; The Word app is owned by my form. TFrmWord is basically just a form with a toolbar, which is designed to sit above the Word app. FrmWord needs: to be visible when the Word app it has created is visible. minimize when the Word app is minimized. Move when the Word app is moved. Resize when the Word app is resized And vice versa for the Word app (ie any movement, resizing, minmimizing etc needs to be relected back to my form). Basically, I am trying to get this to work as if my form and the Word instance are one form. Before anyone suggests, I have tried OLEContainers. They are, of course, buggy, but there are other problems: It is problematic with the Word ribbon when more than one container's open. It has horrific refresh problems when the OLEContainer is moved on to a second monitor. If the user opens a word side panel (eg search or help) and then closes it the Word object does not refresh with the result that there is blank space where the panel used to be and detecting this and trying to refresh is difficult. There were a number of other problems, which I can't remember now, but so many as I gave up the ghost. So I worked with SetWindowPos and timer's instead. It took weeks of trial and error to do what I want it to do and in the end I had it working reasonably well. However, it seems that in a recent Windows update the way SetWindowPos works has changed. Apparently, MS has decided to place further restrictions on one app trying to pop itself on top of another active app. I can understand why, but it has caused problems for the way I have tried to marry up my form and the Word app. Before I spend weeks more time trying to figure out how now to do this, I thought it was worth a post to see if anyone can think of a simpler way of achieving this.

I don't have any experience with Office plugins. I thought about it at the time and it looked difficult and I seem to remember there were certain things I thought I would be unable to do using a plugin. I considered having a look at Add-in Express, but I'm keen to avoid reliance on third party tools as far as possible. I think I'll have a look at it and see if it can do what I want.

In order to pop up a login box I have removed my main form from the autocreation section and I create it in the project file as follows: Application.Initialize; Application.MainFormOnTaskbar := False; Application.CreateForm(TfrmMain, frmMain); Application.Run; The reason I do this is to stop the main form showing if the login process is cancelled. The main form has an initialization and finalization section. If the login process is cancelled so that the main form never shows, the initialization section is called, but the finalization section does not get called. In fact, the app hangs and has to be terminated via task manager. if not DoLogIn(self, CurrServer, MainUser, ltStartUp) then begin Application.Terminate; exit; end; If I insert a Show command prior to Application.Terminate all works as expected. Does anyone know why Application.Terminate does not terminate the app without a call to "Show" and is there aw away around this (other than calling Show)?

Ok. Thanks that makes sense. I was testing whether mainform was assigned in the onCreate event of the first form created.

I have Application.ShowMainForm:=false, but it still flickers after call to terminate. I cannot figure out why it is now doing this. It wasn't when I originally posted and as far as I can see my code is the same. But as mentioned above, there is apparently no mainform.

The "exit" does nothing. I was under the misapprehension that the current function would run to its conclusion even after terminate call. Unfortunately, I have been fiddling around trying to find out how to solve the problem and now I can't recreate it! My main form flashes on the screen at the point of application.terminate and it closes properly. Can't seem to get it back to its original state. Will just have to live with the form momentarily flashing on screen. Thanks for the help.

VCL The form creation code is in the proj file. You can't assign the form as the main form other than in project options. It's readonly. Which has made me realise I don't have a mainform. Maybe that's the problem

No worries

I'm using TWebModule in an ISAPI DLL. I am using it to return data from a database in xml format using IXMLDocument. Last night I had a problem with text data which included characters such as "/". I assume the returned text was being formatted somewhere along the line to insert escape characters with the result that the received xml at the other end is always slightly short so that you end up with a badly formed xml document. So, for example, if the returned text had two "/" characters the xml document when received is short the last two characters. My code on the server side is: Response.Content := doc.XML.Text; Response.ContentLength :=length(doc.XML.text); I also tried determining the ContentLength using "length(Response.Content)", but that made no difference. I edited the data in the database to remove the "/" characters and all worked fine. I have now tried to replicate the problem so that I can seek some advice as to possible causes, but the xml is no longer being truncated. I am puzzled and keen to avoid the issue for the future, but unable to provide any more info because I can't now replicate the problem. Does anyone have any ideas as to what may have caused the problem initially?