Mark Williams

Taken some time for me to resolve the issue. Managed to override the ChangeScale event, but still couldn't get it to work quite right. However, resolved the issue in the end by changing the component container from TPanel to TFrame. I have other components that use image resources for which the fix won't be that simple. But have dug around and discovered the TCustomForm's onBeforeMonitorDPIChanged and onAfterMonitorDPIChanged events and TWinControl's ScaleForPPI procedure. Suspect these in combination will allow me to do what's needed. I'll post back with the results when I get to it.

I have a custom component derived from TPanel. There are several other components included including a TToolBar. There was also a TImageList which loaded bitmaps from a resource file to provide the icons for the toolbar. I'm finally getting around to trying to update this to work with TVirtualImageList and transparent PNG files (24 x 24) rather than bitmaps. It works, but is not scaling properly. On higher resolution monitors the toolbuttons are far too small. I suspect my problem is with the scaling of the toolbar rather than the imagelist. But I'm not entirely sure that's correct or what to do about it. The relevant code is below. FImageList := TVirtualImageList.create(self); FImageList.SetSize(TargetSize, TargetSize); FImageList.ImageCollection := FImageCollection; FImageList.DisabledGrayscale := true; FImageList.Height := 24; FImageList.Width := 24; FToolBar := TToolbar.create(self); FToolBar.parent := self; with FToolBar do begin Height := 36; ButtonWidth := 35; ButtonHeight := 35; align := alTop; ShowHint := true; AutoSize := true; Wrapable := true; end;

As it turns out, I idiotically downloaded an older version from Sourceforge rather than the latest version from Github!

After two long days of updating a huge project to incorporate the latest version of the Windows Ribbon Framework (for some reason it is no longer possible to link ribbon commands with TActions), I am left with one issue I cannot resolve. Previous versions of the framework had a UseDarkMode property which put the ribbon into/out of dark mode. THis has been removed from the latest version of the ribbon. Now it just remains dull grey even if you have dark mode enabled on your PC. I have added the relevant procedure back in to UIRibbon.Pas: procedure TUIRibbon.SetDarkMode(const Value: Boolean); var PropertyStore: IPropertyStore; PropValue: TPropVariant; begin if Assigned(FRibbon) and Supports(FRibbon, IPropertyStore, PropertyStore) then begin UIInitPropertyFromBoolean(UI_PKEY_DarkModeRibbon, Value, PropValue); PropertyStore.SetValue(TPropertyKey(UI_PKEY_DarkModeRibbon), PropValue); PropertyStore.Commit; FDarkMode := True; end; end; But calling this makes no difference. All the other colouring functions have been retained and work, but not this one. Anyone have any idea how to get the ribbon into dark mode please?

I've just updated my version to the latest and have found the the TRibbonApplicationModes set has been removed from UIRibbon.Pas. As far as I can see there is now no way of querying what ApplicationModes are currently deployed. Seems like an odd feature removal. I query these quite a lot. Presumably, you are now expected to keep track of the Application modes yourself. Am I missing something here?

Thanks Peter. That worked a treat.

I'm working on a component derived from a TTabControl. I want to manipulate the individual tabs in various ways. To do so I need to override the DrawTab event. This works well until you activate a theme and then the DrawTab event doesn't fire unless you disable seClient for styleElements., which I don't wish to do as I don't want to have to try and draw the body. If I add a TTabControl to a form and then access its OnDrawTab event, I can override the themed drawing of the tab with a theme active even though seClient styleElements is true. That seems a bit odd to me. I have tried catching various paint messages and tab drawing messages, but nothing seems to fire in my custom control with seClient set to true. Is there a way of doing this?

I posted this a day or so ago. Its disappeared! Thanks for the perseverance. I've given up hope of finding out what's causing this. The FindConnection kludge seems to do the job!

It's the default ie true

The TFDManager's resourceOptions.KeepConnection is the default, which I have tested and is true.

That makes sense. Then presumably calling execute reopens the connection, but this is not happening in this case due to the breach of the specific constraint? I haven't tried setting the SQL before starting the transaction. As there are a series of transactions with rollback on fail, it needs to come after StartTransaction. Is that not what the additional code I added (FindConnection) does? I've tried debugging, tracing, around the setting of the SQL it provides no information whatsoever. Thinking about it, it seems that the most sensible thing to do is to check in the finally block whether or not the connection has been dropped and restore it with FindConnection if needs be before calling commit or rollback, Thanks for the insight.

I am using FireDAC component within an ISAPI DLL to access a PostgreSQL database I create the FDMAnager component on startup: FDManager := TFDManager.Create(Nil); with FDManager do begin ResourceOptions.SilentMode := true; ResourceOptions.AutoReconnect := true; UpdateOptions.CheckRequired := true; UpdateOptions.CheckReadOnly := false; UpdateOptions.CheckUpdatable := false; AddConnectionDef(FD_POOLED_CONN, 'PG', oParams); FDManager.Active := true; end; Each function then creates a TFDQuery component as required and connects to the pooled connection. I then commence a series of transactions within a try...finally block with a rollback if one of the transaction fails. This works fine except I am encountering odd behaviour within one of the transactions. The connection is lost after setting the query's sql.text property even though there is no error when actually setting the query. I get an error when executing the query and this is due to my client app providing the wrong data. This I can fix. I am more concerned as to why the setting of the query property should cause the connection to be lost without without an error being triggered. The relevant code is: try With FDQuery do begin Connection.StartTransaction; if length(insertArr) > 0 then begin AddToLog('1 Before call queryConnection assigned=' + ord(assigned(Connection)).ToString, leDevelopment); ///connection assigned here try SQL.Text := 'INSERT INTO doc_cat_profiles_detail (doc_cats_id, priority, ' + 'auto_disclose, profile_id) VALUES(:DOCCAT, :PRIORITY, :AUTOD, :PROFID)'; AddToLog('SET SQL OK', leDevelopment); //quuery sets fine here except on E: Exception do AddToLog('Exception while setting SQL: ' + E.Message, leCriticalError); end; AddToLog('2 Before call query Connection assigned=' + ord(assigned(Connection)).ToString, leDevelopment); //Connection is lost here Params.BindMode := pbByNumber; Params[0].DataType := ftInteger; Params[1].DataType := ftInteger; Params[2].DataType := ftSmallInt; Params[3].DataType := ftInteger; Params.ArraySize := length(insertArr); for i := 0 to high(insertArr) do begin Params[0].AsIntegers[i] := Profile[insertArr[i]].doc_cat; Params[1].AsIntegers[i] := Profile[insertArr[i]].Priority; Params[2].AsSmallInts[i] := Profile[insertArr[i]].auto_disclose; Params[3].AsIntegers[i] := Profile[insertArr[i]].profile_id; end; try execute(Params.ArraySize); except on E: Exception do begin AddToLog('SaveCategoriesAndProfile - Failed on insert new profile detail' + '. ' + E.Message, leCriticalError); Success := false; exit; end; end; end; Success := true; finally if Success then begin Connection.Commit; SetResponse(Response, 200, 'Success'); end else begin if Connection.InTransaction then Connection.Rollback; SetResponse(Response, 500, 'Internal Server Error', 'SaveCategoriesAndProfile failed', leCriticalError); end; end; The query executes with this error: :insert or update on table "doc_cat_profiles_detail" violates foreign key constraint "ct_delete_prof_details". II am providing invalid profile-ids in the client app. This I can sort. But I can't figure out why setting the SQL.Text property is causing the connection to drop. A FireDAC trace shows nothing. The PostgreSQL log logs the error re the foreign key constraint, but mention no loss of connection. I've added code following the setting of the sql.text: if not assigned(Connection) then begin Connection := FDManager.FindConnection('pooled_connection'); // Restore the connection AddToLog('Connection re-assigned after SQL.Text!', leDevelopment); end; This appears to solve this particular issue, but I am concerned that I may encounter this issue elsewhere in my DLL (which is chunky) and, as it effectively causes the DLL to hang in terms of database communication that could be a major issue.

The code I am using was an example I got off the web. Can't even remember where now! Can't fund the MS documentation for it although I can find the documentation for the Application Host Administration Interface. If I change the call as follows: Site := ServerManager.GetAdminSection('sites', 'system.applicationHost/'); I then get an error advising that the first parameter is not a valid section path in the config file. So I think the return value of an OLEVariant is okay. I think the problem lies with the parameters passed to the function. I think the first param is correct 'system.applicationHost/sites'. I think it is the second param that is causing the problem:'MACHINE/WEBROOT/APPHOST'. The second param is already declared in the call to: ServerManager.CommitPath := 'MACHINE/WEBROOT/APPHOST'; That is that is the path to the config file. The MS documentation for the Application Host Administration Interface states it relates to IIS7 and IIS8 and I am using IIS10, but can't find later documentation and I have tested it a little with IIS10 and seems to work. The documentation declares the GetAdminSection function as HRESULT GetAdminSection( [in, string] BSTR bstrSectionName, [in, string] BSTR bstrPath, [out, retval] IAppHostElement** ppAdminSection ); Calling the function as: GetAdminSection('system.applicationHost/', 'MACHINE/WEBROOT/APPHOST', SitesSection); Results in a run time error that there are too many parameters. This works using thee imported type library, but not as an OLE call. That would suggest that the second parameter in the OLE call is also correct. As you can probably see I am floundering! I guess I will have to work with the rather yuk interface! Thanks for your help.

I had started to go down this route. I'm using the 64 bit type library, which is even more of a pain to use. It does seem to work however. Thanks for the reference to the dotnet wrapper.

Same result. It reports true for Server Manager, but then fails with the variant does not reference... error on the call to ServerManager.GetAdminSection.