Forum Replies Created
-
Posts
-
'Support' wrote:
I will add some changes in the v10.01, you will be able to evaluate it
Great, thanks!
Quote:I have made a test app for this issue, glyphs are changed in run-time there.. Could you give me your demo-app?Sure, I have attached it. In the demo you can change the Action via the combo box. Even though the glyph doesn't change, when you mouse over the TsSpeedButton the popup hint shows that the underlying Action has indeed changed.
Quote:Buttons surroubded in blue are not skinned? You can change the SkinData.SkinSection property to unexisiting section (to 'NA' for example). Control will not be skinned in this case.Correct, the one in blue was not skinned. Your suggestion seems to work just fine, so thanks again!
Both options sound like they would work, but A is definitely easier to implement. Fortunately in my project all the code for displaying prompts is centralized in one location, which made it really simple to use the sMessageDlg function.
Anyway, thanks for your help as always! Kudos for already having skinned replacements for those standard dialog functions too! 🙄
'Support' wrote:Hello!
Why buttons are not skinned there? It's not a standard dialog? Could you send me a demo, please?
I've attached a demo, and I think I came across the source of the problem. The function I'm using to display text prompts is the Dialogs.MessageDlg method (part of the standard VCL library). Things seems to work fine when the TsSkinManager.SkinningRules property includes the srThirdParty option, but not when that option is off.
I'm guessing the MessageDlg method is using some sort of custom dialog with TLabel components, and these labels aren't skinned properly unless the srThirdParty option is also set. The big problem with the srThirdParty option (and why we have it turned off) is it screws up like 95% of the frames in our software. When this is set, TLabel controls throughout the software (that we don't want skinned) end up being drawn with skin colors (see the green text in the attached screenshot).
[attachment=6753:AC Screenshot 1.png]
I see two main options here:
A. Continue setting srThirdParty to false. Modify my text prompt class to use a compatible standard dialog (or perhaps a new dialog created by me) that will correctly display text using the current AC skin.
B. Change srThirdParty setting to true. This is really only feasible if there's an easy way to fix the display problems that result (TLabel controls everywhere are now drawn with skin colors instead of the desired clWindowText).
Maybe there are other options (changes in a future version of AC?), so I'll rely on you experts to help guide me.
'mol' wrote:Well, you wanted to get rid of the border… 😉
Here's another approach which should work: http://delphidabbler.com/tips/74
Lol true… thanks for the link too. I might have to dabble with making my own control at some point.
Quote:Don't know; I hardly ever work with transparency. If I recall correctly, there are always problems associated with TWinControls and transparency. What happens if you put those on a semi-transparent TFrame? Isn't the painting too much of a hassle?
-Uwe
You're probably right (the article you linked indicates as much), but somehow the people behind AC have already got it working pretty well. I've found a few little issues over the years, but most or all of them have been resolved by the AC developers. The image I posted in my first post highlights a new issue I found, but that should be fixable as well.
They have already done the hard work of making transparency work, so why not wrap that functionality in a more lightweight component that doesn't carry all the extra TPanel/TsPanel baggage? AC gives us these beautifully skinned forms and panels, which only increases my desire to embed transparent frames and panels within them.
'mol' wrote:I would think so. You could derive your own groupbox and override the paint method (untested):
You could do much the same with practically any TWinControl descendent, no? Also, the code you posted will overwrite the group box's client area, the opposite of transparent. Simply NOT painting anything can work (if I remember right), but I also recall this introducing certain visual artifacts.
You don't even have to derive your own component to make a TPanel transparent, but as I mentioned before, it doesn't always play nicely with Alpha Controls. It just makes sense (to me) to have a standard, lightweight, invisible component that does nothing more than group other child controls together for alignment, sizing, and other similar layout purposes.
Another common thing I like to do is nest a TFrame inside another TFrame or TForm (it helps organize and compartmentalize really complicated forms/frames that otherwise would have thousands of lines of code in them). However, in order to get a nested child frame to be partially transparent, I have to add a TsFrameAdapter and set its SkinSection to CHECKBOX. Wouldn't a new TRANSPARENT setting make more sense (and be more obvious to new users)?
'mol' wrote:A groupbox is not an option?
Can the border on TGroupBox be made invisible? Either way, TPanel can also work, it just seems like overkill. It also doesn't work well with Alpha Controls, which is why I often have to use TsPanel with a CHECKBOX SkinSection. Even then, there are still issues.
I just wanted to thank you for fixing this. After downloading the latest version I noticed this issue has now been resolved for all skins I tested.
We continue to be impressed by this product. Keep up the great work!
Of course, I've attached a simple program demonstrating the problem.
The Android OS skin looks like it was fixed, but there are several skins still suffering from this problem:
Aluminium
iOS dark
iOS4
LikeOperaStyle
Pulsar
Smoky
Subway
Vista
I've run into this a bit myself when switching back and forth between the latest beta and 8.20. It's been awhile since I've worked on component creation, but don't Delphi properties allow you to specify a default value that isn't saved inside the DFM? If so, why not set the default value for Angle as 0? That way the vast majority of new TsLabelFX controls out there with an Angle of 0 won't actually save this value into the DFM, right?
Yes that does indeed fix the problems. For some reason I thought the frames were automatically skinned. Anyway, thank you for helping me out. 🙄
I still get weird issues whether the parent panel is skinned or not. Even though the nested frame looks good in your demo, I don't want the outer panel to have any sort of border or background. In other words, I want the underlying background of the main form to show through, because with your skins it looks great! Unfortunately, if I make the parent panel a TsPanel with its SkinSection set to CHECKBOX, it looks pretty terrible during resizing. This also depends on the skin. MacMetal works a lot better than Topaz, for example. I've attached an updated demo project so you can see what I mean.
Basically I want the parent panel to be an invisible, transparent container. I only want to use it so child controls inside it know how much space they have to work with. Before using your controls, I would just use a normal TPanel and make it transparent, but ideally there would be a better way! It would be so awesome if you had a new, custom control specifically for this purpose. In other words, a transparent container (descended from TWinControl) to help group and align child controls.
[attachment=6318:Prototype.zip]
I have just downloaded, rebuilt, and tested the 8.31 demo build. Unfortunately, it doesn't appear to have fixed the two issues I mentioned here. I also double checked to make sure my sample project is using the new files, and in the designer it shows version 8.31.
I just noticed another issue, though I'm not sure whether it's a bug or whether it was designed this way. Regardless it's related to highlighted text so I decided to just add it to this thread. Again, refer to the screenshot:
It's obvious when the active control has something highlighted, but you can see for this particular skin that the unfocused controls don't show their highlighted text nearly as well. This is a skin-specific issue, as some skins show their highlighted items much better than others. My guess is that you are using the same standard colors to show active and inactive highlighted items, so for some skins it looks good and others it doesn't. My suggestion would be to make the colors used match the rest of the skin, and at least make it so they stand out from the surrounding control.
Thanks again for making an awesome product!
I tried my nested form in 6.54, but with the form's skin section set to PANEL it still wasn't properly painting the inside part of the form's client (just like in my last screenshot).
In the meantime, I've actually started changing the nested forms to all be TFrames that use FrameAdapters, and these seem to be working much better so far. I was initially thinking I couldn't get my forms to work as TFrames, but it seems now they probably will. For now I wouldn't worry too much about making nested forms work, at least not for me.
Here's another weird thing I've noticed with using AlphaControls and nested forms:
Before I was trying to make the child form's client area be transparent using a TsSkinProvider within the form and setting its SkinSection to CHECKBOX. You updated the controls to make this work (mostly), but now I'm thinking it would be better to have the child form completely fill out its parent's area and make itself look like a panel.
I made a simple form with a TsSkinProvider and set its SkinSection to PANEL_LOW. When nested, the form appears to draw its borders properly (using the PANEL_LOW skin data), but the rest of its client area ends up being just a solid color (white for this particular skin). Would it be possible to get this working anytime soon?
Edit: After some additional testing, it looks like you've already done this sort of thing for TFrames with the TsFrameProvider control. We're using TForms instead of TFrames because of all the extra methods and properties you get with forms, and trying to convert all our nested TForms to TFrames would most likely be a major pain. Among other things, TFrames don't have events that let you know when they've been made visible, closed, or destroyed, while TForms do.
If you can basically get the SkinProvider to work for nested forms the same way TsFrameProvider is already working for nested frames, I know I personally would be very pleased. Again, I know this seems weird, but we often have multiple levels of forms all nested together, so getting them all to display properly would open the doors to all sorts of cool possibilities. Thanks again!
