Forum Replies Created
-
Posts
-
You can use the test app I supplied for the Afterburner issue to test this one:
1. Download the AlphaSkins.zip attached to the issue [topic='here']http://www.alphaskins.com/forum/index.php?showtopic=7110[/topic].
2. On line 26 of udMain.pas, change the skin path to the correct path on your PC.
3. Compile and run the program.
4. Click the button to load the skins.
5. Select the Toxic skin in the memo.
6. Notice the TsSpeedButton on the TsPanel to the right turns silver.
7. Click on the TsPanel and the background should change to blue, the TsSpeedButton stays silver.
8. Change the skin to NextAlpha and notice that the button color changes to match the skin.
9. Clicking through the list of skins will allow you to rapidly identify those with the transparency and border issues.
HTH
Further investigation reveals this issue exists in other skins too. Some skins don't respect the border property either; I've documented this for some skins but it is a separate issue and may be by design.
Skins that don't respect transparency:
- Air
- Android OS
- Calcium
- Deep Purple
- Lucky
- Nautilus
- NeonNight
- Neutral2
- Neutral3
- Pulsar
- Smoky
- Snow Leopard
- Toxic
- Ubuntu
- Windows 8
- Winter2011
- WOT
Skin that respect transparency but not borders:
- Bejing
- Blue Plastic
- LikeOperaStyle
- Longhorn
- NextAlpha2
- Office 12
- Opus
- Steam
- Vienna
- Vienna Ext
- XPLuna
- XPSilver
- WMP 2008
- WMP11
- There may be more on this list, I wasn't thorough with this issue
Regards,
Hamilton
Hi,
I've been thinking about this and I don't think the skinning will work for the planner components in any 3rd party suite as they will not descend from any base class that the AC library knows how to handle. What you can do is manually set the various colour regions of the calendar component at runtime to match the skin.
Confirmation that you won't be able to skin the TMS calendar component is: [topic='here']http://www.alphaskins.com/forum/index.php?showtopic=7038[/topic].
If you want to set the colours manually, then you can do something like:
Code: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;
end;This code sets up a TsCategoryPanel to look as if it were skinned; you could adapt this to suit your existing calendar controls perhaps. Please note though that this will just use the colors from the skin, it won't do the borders correctly or add gradients etc.
Sorry I cannot be of more help but I think this is the best you will be able to achieve without a *lot* of dev work.
Regards,
Hamilton
Hi,
My guess would be that your DFM file has a property that doesn't exist for your version of AC Controls. Normally if you open the form in the IDE it will prompt you about this and remove them for you. What you may need to do in your case though is to look at the form DFM (view the form, press ALT-F12 to show the form code) then search for a line that mentions ThirdScrollControl and delete that, then recompile your program and run it again. If you can't find that text in that form then look in other forms that you may be opening, I'm sure you'll find it in there somewhere (use a text editor to view the .dfm files if you don't know a better method). Good luck!
Regards,
Hamilton
Just to confirm: I tested this with AC 7.66 with the same results as OP. Further testing shows that the problem is caused by the ExtendedBorders, irrespective of what skin is being used.
Regards,
Hamilton
I don't use the translation tool myself so I cannot comment on that but I can say that I've manually converted a number of apps over the years. If you have hundreds of forms then you may want to pursue why the conversion isn't working but if you want a solution that would allow you to do the conversion *now* then I'd recommend starting by manually updating one or more forms manually as outlined below:
1. View the form in the editor and press ALT-F12 to shown the DFM.
2. Search/replace TPanel for TsPanel (for example)
3. Press ALT-F12 to show the form, then F12 to show the code.
4. Press F3 to repeat the search and replace.
5. Repeat steps 1-4 for each control you want to replace.
6. Click Save.
You can either update all of your forms manually or once you're comfortable with the process you may prefer to use a global search and replace. You will need however to open each form in turn and allow the IDE to add the AC units to the uses section.
Good luck!
Regards,
Hamilton
I was avoiding answering this as I don't have time to test it but with no official reply I thought I'd just suggest that TBX has it's own skinning engine that is almost certainly interfering with the way AC controls are drawn. I haven't used TBX for a few years so I don't remember if the control component allows the skinning to be disabled – if it does you should start with that.
I'm surprised you're still using TBX btw, I thought everyone had switched to the sp library these days. Legacy app? IMO you're better off migrating to pure AC controls if you're able as TBX has not been supported for years.
Regards,
Hamilton
Hi Serge,
Testing this with version 7.66 released on the weekend I can see that the TsCheckBox font color will change from blue to white with focus (and vice verse) but the background behind the tick does not seem to change when the TsCheckBox is checked, but it does change if the TsCheckBox is not checked. I've included picture of the 4 states (checked/not-checked with focus/no-focus) in the attached screen shot.
Comparing this with other skins, say Light Board and Office12, those other styles seem to change the border around the checkbox but not the colors in the box whereas AutumnSky seems to leave the border unchanged but draws the box colours a different shade (it also changes the font color, which the other skins don't do). It may be that the tick with the AutumnSky skin is drawing over the top of the affected region and masking the visible indicators of the state change in the box? Or maybe changing the font is enough of an indicator?
IMO having the checkbox border or color change too would be make the state clearer but if you disagree, or cannot repro, the control is functional as it stands.
Regards,
Hamilton
I can repro this using the demo with Delphi 2010 and the latest AC.
A couple of observations:
* The same behaviour is observed if the menu is assigned at design time, so that part of the demo isn't pertinent.
* As the main form in the demo states, the problem only exists when the form is maximized.
* If you add sSkinManager1.UpdateSkin after ShowMessage then it fixes the problem.
The third observation above allows a workaround for now and perhaps a clue as to how this may be fixed in a subsequent release. HTH
[EDIT: Fixed typo]
Regards,
Hamilton
Hi Serge,
I had turned off support for 3rd party controls for some reason I can't recall; turning them back on fixes the issue with the dialog text. I'll leave them on and see if there is any other side effect but nothing is apparent at first glance.
The animation for the checkbox is nice but there is an issue that after you check the checkbox the animation doesn't work any more. To repro, just put a checkbox on the form. Notice the mouseover effect. Check the checkbox, there is now no animation. Uncheck the checkbox again, there is still no animation.
I'm not sure if the white dots are visible non-skinned, I'll have to test this another time. Like I said at the start though this isn't a big issue for me but I'll do what I can to help fix it.
Regards,
Hamilton
Hi Serge,
It's exciting to see an ACExtras set – it makes me very keen to see what might be forthcoming in this area 🙂
I only had time for a quick play with the control and my first impression is that it is a very good 'first stab'. The appearance of the headers and the skin effects mean that this control looks better than the VCL equivalent and some aspects of the operation of the control are better as well. There are a number of issues however, some of which may just be personal taste but I'll bring them all to your attention to assess:
* There doesn't appear to be any way to change the height of the panels.
* The chevron indicator in the TsCategoryPanelGroup is not present so there is no indicator that the panel can be collapsed/expanded, at least not in the same way that Windows uses the control and users would likely be familiar with.
* There are a few too many lines for my taste. Overall I find the TsCategoryPanelGroup to be a little 'cleaner'
* The scroll bar needs some work. It's too narrow and the indicator (grab bar) is too tall – which makes it harder for some users to click and if the scroll region isn't large then the indicator can end up being taller than the region. With some skins the indicator wasn't visible and with some form resizing it grew to fill the entire scroll bar and wouldn't scroll any more. Personally I'd like to see the scroll bar match the rest of the scroll bars in my app rather than introduce something that looks so different.
* There are some issues with the focus. I don't know if you really need to make the control able to be focused, but if you do then you need to fix it as currently you can have the focus color on multiple groups at the same time.
The attached image demonstrates a few of the issues outlined above. The image shows a TsMemo, TacFloatPanel and TCategoryPanel from left to right. Issues you might notice are:
* Two panels have the orange focus color.
* The scroll indicator on the TacFloatPanel doesn't indicate position.
* 3 controls, 3 different types of scroll bar.. Not so nice.
There may be more but gtg, I look forward to your response.
Regards,
Hamilton
Hi,
I'm using TsComboBox in several commercial applications without ever seeing anything like you describe so my suspicion is that you've either found some bizarre corner case or more likely your combo selection has an unintended side effect. Can you modify your code so that when the form is first displayed you don't manipulate the combo at all – that way you could test that the items were still there at the start at least. Another idea – if you replace your TsComboBox with a TComboBox do you get the same effect – if you do then you know it is your code at fault. If you are able to post code then I'd help you debug but I am quite sure that this will not turn out to be an AC control issue.
Good luck 🙂
Regards,
Hamilton
For a quick fix – if you change the SkinData.SkinSection to BUTTON then you may get the effect you want. I tested this with Office 2007 Black and it looks OK but try some of the other sections if it doesn't suit your taste. Good luck!
Hi Gino,
If you have a GroupIndex of 0 I would expect that you wouldn't see the down state at all and that the button would return to the default original state as soon as you clicked it? If you have a couple of buttons with a GroupIndex of 1 then I can see the problem that you describe with the Office 2007 Black skin however – the down state and the mouseover state are way too similar. If you look very closely then you'll notice that the down state draws the button orange with a brown(ish) border on the left and top sides, but the mouseover has a white(ish) line in those places instead. You should be able to use the skin editor to change the way one of those effects is drawn but it would be much better if the skin itself was fixed.
Serge – can you change the Office 2007 Black skin to have more variance between the mouseover and down states on TsSpeedButton?
EDIT – Realized you can see the down state while the mouse remains clicked. Doesn't affect other details of my post.
Regards,
Hamilton
Hi Gino,
What skin are you using? I tested TsSpeedButtons with several skins and the down and mouseover drawing were different and distinct for all of them. For the web2 skin for instance, the mouseover effect turns the button orange and the down state draws the button as a darker shade of blue than the normal state. Once the button is down if you do the mouseover again the button remains drawn in the down state (there is no indicator that the mouse is over the button) but I think this is the expected behaviour. I wonder if the problem you're describing is that the button remains in a down state after you've stopped clicking on it? – if that is the case it's not a skin issue, its a behaviour caused by the way the button is setup and you'll either want to set the button group to 0 so it doesn't have a down state or manually control the down state. Let me know if I've misunderstood your problem.
Regards,
Hamilton
Hi,
1. Selection color is now good when the grid has focus and when it does not have focus.
2. Dialog.png (attached) shows the black text on dark blue with a MessageDlg. The same problem exists with ShowMessage. I didn't test other dialogs.
3. Checkbox animation – TBA – looking forward to seeing what you come up with.
4. Panel.png (attached) shows a form with a TsMemo on the left, a top aligned panel and a right aligned panel with several other panels aligned within it. I've used red circles to show the dots in the screen shot. The white pixel in the corner appears to be caused by the panel being next to certain other controls – in this case the TsMemo. The panels that are inside another panel do not get white corners, the other two panels on the form do get white corners, even on the corners that are not next to the memo. In my actual application it isn't a memo causing the white corners, it is either a cxGrid or a TsPageControl, but the effect is the same.
PS This is a really nice looking skin Serge, cheers!
HTH
Regards,
Hamilton
Hi Serge,
The file is missing the word 'class' at the beginning of line 720; after adding that word the file will compile.
Other than the missing word, the update if fantastic. It has affected all the skins I noticed; I tested with 14 different skins and the only one now that doesn't have a clear selection is Office12Style (for that skin the problem I reported for LightBoard exists after this update, for all other skins there is a vast improvement).
Many thanks for the fast solution once more.
Regards,
Hamilton
Hey,
I did some testing on that control and found that the color is being set by the skin. For most AC controls you can set the SkinData.CustomColor property and that allows you to override the color but that isn't working for this control (this may be a bug or intended design idk).
What you can do to get it working now is change the SkinData.SkinSection to something other than GAUGE – I found that pressing DELETE so there is no skin section at all worked fine (it will show as UNKNOWN), but you may want to make it a PANEL or something else if you want to effect the way the border and other details of the control are drawn.
I hope that helps, best of luck.
Regards,
Hamilton
