[Hamilton]

This link shows how to set the border. Again, I haven't tested it so GL!

http://www.swissdelp…ode.php?id=1171

[Hamilton]

I found this code that may help you. Didn't have time to test it sorry and it doesn't address the frame color; I'm hoping that if this works you'll be able to use it to decipher the rest of the puzzle. GL!

Code:

with WebBrowser1 do
begin
OleObject.document.body.Style.scrollbarFaceColor := '#FF6699';
OleObject.Document.body.Style.scrollbarTrackColor := '#CCCC99';
OleObject.document.body.Style.scrollbarHighlightColor := '#99FF99';
OleObject.document.body.Style.scrollbar3DLightColor := '#6699CC';
OleObject.Document.body.Style.scrollbarShadowColor := '#6600FF';
OleObject.document.body.Style.scrollbarDarkShadowColor := '#00CC66';
OleObject.document.body.Style.scrollbarArrowColor := '#336699';
end;

Another snippet, though it is probably bad practice to do this unless you have control over the pages being viewed:

Code:

WebBrowser1.OleObject.Document.bgColor := '#000000';

[Hamilton]

The code for ResetColor lost it's formatting when I copied it into this thread; please refer to the formatted code for the same function at http://www.alphaskin…?showtopic=6544 instead.

[Hamilton]

I don't have a good reply for ya but no one else has jumped in so I thought I'd offer something! Anyway I wouldn't do component development for a one-off use myself, and would recommend doing something manual like the code below which does a similar thing for a TsCategoryPanel.

procedure TfdPOSDesigner.ResetColour;
begin
cpgProperties.Color := sSkinManager1.GetActiveEditColor;
cpgProperties.GradientBaseColor := sSkinManager1.GetActiveEditColor;
cpgProperties.GradientColor := sSkinManager1.GetHighLightColor;
cpgProperties.HeaderFont.Color := sSkinManager1.GetActiveEditFontColor;
cpgProperties.ChevronColor := sSkinManager1.GetActiveEditFontColor;
cpgProperties.ChevronHotColor := sSkinManager1.GetHighLightFontColor;

CategoryPanel1.Color := sSkinManager1.GetGlobalColor;
CategoryPanel1.Font.Color := sSkinManager1.GetGlobalFontColor;
CategoryPanel2.Color := sSkinManager1.GetGlobalColor;
CategoryPanel2.Font.Color := sSkinManager1.GetGlobalFontColor;
CategoryPanel3.Color := sSkinManager1.GetGlobalColor;
CategoryPanel3.Font.Color := sSkinManager1.GetGlobalFontColor;

Basically what I'm suggesting is to use the skin color that you can get a handle to conveniently and using those to manually skin the component. You could implement the call to ResetColor in an inherited Create event or similar, or call it manually in your code in FormCreate or similar. Something like:

TMyWebBrowser = class(TWebBrowser)

private

procedure ResetColor;

public

constructor Create(Sender: TObject); override;

end;

TMyWebBrowser.Create(Sender: TObject);

begin

inherited;

ResetColor;

end;

end;

[Hamilton]

Hi Serge,

I reimported the skins and can see that the ones that didn't draw a border before do now, which is good.

The primary issue with the transparency has not been affected from what I can see; skins like BlueGlass that did use semi-transparency or full transparency before still do so, and those that did not before still do not. In my view this is a bug rather than a feature of the skin because the flat property is being ignored, and not a minor bug either given that this is the accepted standard way to color a button in Delphi.

At the moment the screens that rely on this feature are in beta release only and I'm able to tell the clients to choose a skin that does work. Prior to the full release in the middle of next month however I'll either have to get the skins fixed, set up a specific skin just for the affected forms, or use TSpeedButtons and turn off the skinning of those controls – so please let me know as soon as you're able if you think this is fixable or I'll have to implement a workaround.

I think the problem is well understood but I've uploaded two screen shots that show one of my screens with BlueGlass and Android OS skins; the BlueGlass skins works how I'd like but the Android skin isn't usable for my purpose in it's current state.

PS I still haven't touched the CommonSections property you mentioned and have no idea how to use that property or if it is required.

Regards,

Hamilton

[Hamilton]

My pleasure.

Another workaround is to set the HintPos values specifically; in sAlphaHints1ShowHint instead of manipulating HintInfo.HintPos if you just set HintPos specifically that will work too, and you won't have to change both the x and y coords if you do this (but it may have other side effects I haven't considered so perhaps your original solution is best after all). Anyway just throwing it out there!

Serge: can you please fix the bug that IPSteven pointed out; the line of code should be:

Code:

if (FHintPos.x <> HintInfo.HintPos.x) or (FHintPos.y <> HintInfo.HintPos.y) then FHintPos := HintInfo.HintPos else begin

Regards,

Hamilton

[Hamilton]

NB: For the panel make sure the SkinData.CustomColor flag is set to TRUE.

[Hamilton]

AFAIK you cannot do this; to achieve a similar result I've always used a TsSpeedButton on a TsPanel; if you make the panel have your desired color then set the TsSpeedButton to be flat and transparent then voila you have colored buttons. Please note though that this does *not* work for all skins (ref: [topic='7109']here[/topic]).

Good luck!

PS I have no idea how you managed to color a TBitBtn! As I understand it, that control uses the Windows comctl library to render the control and that means the color comes from the Windows theme – so to change the colour you would have to put a panel over the button, reimplement all the mouseover and click funtionality, redo the borders, redraw the text etc – all of which would be horrible! How did you do this?!

Regards,

Hamilton

[Hamilton]

Hi IPSteven,

I traced through the code and can see that the TsAlphaHints component has it's own OnShowHint method; if you put the code to manipulate the hint position (and color etc) in that event handler rather than the Application.OnShowHint method then everything will work as you expect. I tested setting the absolute and relative position and both worked as you would expect.

Aside: Setting the color in the OnShowHint method did not work but that is probably part of the design, I didn't use the SkinManager to see if this could be controlled as it is outside the scope of the OP.

Anyway good luck!

Regards,

Hamilton

[Hamilton]

That link doesn't appear to be working so hopefully Embarcadero don't mind me posting their sample code:

Code:

procedure TForm1.DoShowHint(var HintStr: String; var CanShow: Boolean; var HintInfo: THintInfo);
begin
if HintInfo.HintControl = SpeedButton3 then
begin
with HintInfo do
begin
HintColor := clAqua;{ Changes only for this hint. }
HintMaxWidth := 120;{Hint text word wraps if width is greater than 120. }
Inc(HintPos.X, SpeedButton3.Width); { Move hint to the right edge. }
end;
end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
Application.ShowHint := True;
Application.OnShowHint := DoShowHint;
end;

[Hamilton]

Hi IPSteven,

I haven't used TsAlphaHints but the generic code may allow you to do what you're after:

http://docwiki.embarcadero.com/CodeSamples/en/OnShowHint_(Delphi)

Regards,

Hamilton.

[Hamilton]

Hi,

My TsSpeedButtons are all flat, it's the only way to get transparency, but as you say this doesn't work for all skins. You mention that you have updated them – will they be available in the next release and fix the problem or will I need to do something with CommonSections too? If I do need to change the CommonSections property can you please tell me what values it is expecting as I have no idea how to use that property.

Cheers Serge and chat soon.

Regards,

Hamilton

[Hamilton]

If you do get the dialog to work then you might want to replace it with your own custom form anyway because it doesn't look 'perfect' with most skins; for instance, the buttons text fits very tightly and the skins that change the font (most of them) often cause the button caption to wrap to a second line. Also, I know I don't use these dialogs in any of my apps because they used to be *extremely* buggy and unreliable (disclaimer: that may be a bias from a long time ago that is no longer warranted). GL.

Regards,

Hamilton

[Hamilton]

I can't repro this error with the latest AC and Delphi 2010. Have you set the Customizable flag of the TsToolBar?

Regards,

Hamilton

[Hamilton]

Hi CheshireCat,

Thanks for that. I tried the modified skin and found that whilst the transparency is now enabled I still don't have borders, and the color when a speedbutton has focus is strange (it is semi transparent but not transparent enough – which means the base color is modified by such an extent that some very strange and unattractive colors result, and also the legibility of any text on the button is greatly affected).

I emailed support about this issue last week and received a reply this morning and they are looking into a solution that will fix the issue for all of the skins I listed. I'm waiting to see what comes of that and will post the results back here when we have a solution.

Anyway I wouldn't spend too much time working on a solution for one skin when a global fix may be in the works but I do greatly appreciate your effort. Thanks again for your time 🙂

Regards,

Hamilton

[Hamilton]

I retested TOOLBUTTON after talking with support and found that it does give transparency but loses the borders. I don't know why my previous test results were different but I most likely made a mistake. Anyway TOOLBUTTON does solve the problem I stated but creates a new one so I cannot use this solution. If there is no real solution or workaround to this issue I'll have to remove a bundle of skins that I, and many of our clients, like because they will not be compatible with all the program, and I don't want to have to do that! Using a separate skin for that form is perhaps an alternative I would consider but really would like this fixed not me having to work around limitations 🙂 IMO controls should always respect the properties. If you change the skin section is should change the way that the control is drawn, but the actual control properties should always be the final determinant as to whether or not some features are drawn at all (such as borders). What do others think, and what do you think Serge – can this be fixed?

Regards,

Hamilton

[Hamilton]

Nice, thank you. The updated skin works as expected.

Regards,

Hamilton

[Hamilton]

Nice, thank you. The updated skin works as expected.

Regards,

Hamilton

[Hamilton]

Thanks CheshireCat 🙂 Nice skin btw! If you link the skin here I'll test it for you, otherwise I look forward to seeing it in the next release.

Regards,

Hamilton

[Hamilton]

Hi CheshireCat, it's a good suggestion that works in many situations but doesn't help in this case unfortunately. With Toxic and the other skins I mentioned it seems that the transparency is ignored for all the SkinSections that I tried.

Regards,

Hamilton

[Author]

Posts