Mark Williams

Had a quick look. Very interesting. Looks like quite a bit of work to produce a large app and also I think it requires replacement of all visual components with their own. Couldnt't see some fast conversion script for this. Maybe it's as easy as copy and replace of pas and dfm file class names. However, I rely significantly on virtualTreeView for display of db data. I don't think the treeview they provide would be suitable. Could convert to TListView, but I couldn't find that as an option on their components page. I don't use DGGrid's for various reasons, but could always consider that. All the same, worth keeping an eye and it could well be useful for "light" version of desktop apps.

That all sounds very promising. Thanks for the comments. My app is fairly heavy duty and with a huge executable (which seems to be par for the course with Delph nowadays). It needs to access several dlls and an ocx. The ocx is mine and could be (possibly should have been) written as a dll. Are there any issues you know of with dlls? I use theming and would like to retain it, but it's clients who are asking for possibility of cloud app, so they can make the choice of living without it. I can keep in the desktop app version. I was under the impression that the license fee charged by Cybelesoft included the hosting of the app. However, the hosting shouldn't be a problem. Each client would probably set up their own internal and external servers to host it. That leads to another question and that's what sort of degradation in speed have you experienced between desktop and cloud? What is actually involved in redeveloping as a web app? Is it possible in Delphi? I haven't seen anything anywhere dealing with this.

Thanks for the link. It didn't seem to work for me. However, it gave me the idea to change my function to repaint the background of the glyph. Now works and will have to do for now. Function GetTransparentImageList(Owner:TComponent; SourceImages:TImageList; BMPIndex:Integer):TImageList; var bmp:TBitmap; begin bmp:=TBitmap.Create; try if SourceImages.GetBitmap(BMPIndex, bmp) then begin Result:=TImageList.Create(Owner); With Result do begin bmp.Canvas.Brush.Color:=StyleServices.GetSystemColor(clWindow);; bmp.Canvas.FloodFill(0, 0, bmp.canvas.Pixels[0, 0], fsSurface); AddMasked(bmp, clFuchsia); end; end; finally bmp.Free; end; end;

From within an app I save data obtained over the internet from a database to a local file so that when the user needs to reopen it can be loaded locally rather than across the net. Also, the user can save other data they are working on for later restoration. My inclination is to place these file in "C:\ProgramData" (CSIDL_COMMON_APPDATA), but I notice Embarcadero, for example, save new projects off "C:\Users\Public\Public Documents". Foxit also use it. Two questions: What is considered best practice for storing this sort of data? How do you get the "C:\Users\Public\Public Documents"? There doesn't appear to be a constant value to use with SHGetFolderPathA to get it. All I can find is CSIDL_COMMON_DOCUMENTS and that gets "C:\User\Public\Documents", which doesn't exist on my version of Windows10.

That's what I've opted for. Thanks.

I don't actually want them to know where the data is and I also want it to be shared amongst anyone else who has access to the app, but only via my app.

And TMyObject(SL[index]).Something Where SL is a TStrings. If I had a dollar for every time...

Ah yes! Thanks

Damn tricky fellas! I should have realised that! It's the third option. So I will place in Public Documents ShellGetFolderPath(CSIDL_COMMON_DOCUMENTS, Path); path := includeTrailingPathDelimiter(path); stream.saveToFile(path+'stream.txt'); Saves to C:\Users\Public\Public Documents' . So all is good. I don't actually want users to try and open the files directly from the folder. My app just needs to know where they are so it can build a list of them (FindFirst...) and offer them via the app for opening. They could be anywhere as far as the app is concerned, it just needs to know how to find them.

I make that error quite often. I've often wondered why the compiler doesn't pick it up.

Does anyone know a way of getting the above to function in 64 bit or is there an alternative?

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