[HeDiBo]

'Support' wrote:

I will add more properties soon.

The OnClick event exists there, this event is published in the TsArcControl component, TsRoundBtn is inherited from TsArcControl.

You haven't this event in the object inspector?

Yes. I was talking about the Click method.

[HeDiBo]

Another problem with SkinManager is this:

My SkinManager is placed on a DataModule. When I change the list of internal skins, and I close the project, Delphi does not see the change in SkinManager.InternalSkins. Therefore the change gets lost.

I think this is a simple oversight, easily corrected.

With respect of being unable to “Update All” internal skins, I tested that when I was sure, the DataModule was saved.

[HeDiBo]

'Support' wrote:

Internal skins should be updated after clicking the “Update all” button, even if renamed.

This feature doesn't work? Maybe you should remove all skins from list and add it again (old names will be stored in this case).

Strangest thing is: it works if you do it in the same Delphi session. However, if you terminate Delphi and restart it, the same problem occurs.

I have deleted and re-added these skins already several times. Always with the same result. I also downloaded one of the offending skins from the skin gallery: but it's the same skin, so that's not the problem either.

When I rebuild the latest AlphaSkins components, I always delete all old DCU's, DCP's and BPL's before regenerating. So, it can't be old stuff hanging around.

[HeDiBo]

'Support' wrote:

Described feature will be implemented in the v12.06

Maybe I explained it wrongly.

My application is delivered with Internal Skins only.

Many of the internal skins are renamed to Dutch equivalents.

If I click “Update All” in the list if Internal Skins, none of the skins with a translated name are updated. I get the message: “These skins are not updated: ” followed by a list of renamed skin names.

My idea was that “Update All” would go for an update, using the original name, not the translated name. This would require that the Skin manager would maintain a list of original skin names against which the update would be done.

In that way, skin manager could also have a method for setting a skin using the original skin name (OrgSkinName := 'Notes Leather' would do the same as SkinName := 'Leder'). That would make the application easily localizable.

[HeDiBo]

'HeDiBo' wrote:

When skins lack the TB_BTN section, what section do you use for TitleBar buttons from TsTitleBar? (I thought the TB in TB_BTN stood for TitleBar.)

I think problem is solved in 12.12

[HeDiBo]

'HeDiBo' wrote:

There are a lot of normal button things missing:

• The events OnEnter, OnExit, OnKeyUp, OnKeyDown and OnKeyPress.[*]The method Click.[*]These properties would be nice also: Blend, DisabledImageIndex, DisabledKind, Glyph, ImageIndexSelected, Transparent, UseEllipsis and WordWrap.

Thanks ;-}

No change in 12.12. Especially the Click method is missed.

[HeDiBo]

'Support' wrote:

Yes, skinning of DevEx controls is handled via other way, support of these controls by adding into ThirdParty list is difficult.

I will check and I will try to add support of the TcxSpinEdit soon.

Well, I have the other controls working through the ThirdParty list. For instance the TcxComboBox is handled as a general COMBOBOX and works fine.

So, a more general solution would be to make possible to add a control with SPINEDIT properties to the possible controls in the ThirdParty list.

[HeDiBo]

'Support' wrote:

Changed in the v12.11

Thanks

[HeDiBo]

'HeDiBo' wrote:

The bar below the main menu is a standard TToolbar. The controls on the toolbar that are skinned wrong are a TcxComboBox and a TcxSpinEdit. I thought these would be skinned by acLFPainter if environment variable DEVEX2011 was set.

The TcxComboBox could be added easily to ExternalControls as ComboBox. That did the trick.

Adding TcxSpinEdit as an UpDownBtn does not make it look better (different, but not better).

The controls beneath the toolbar are a whole different cup of tea. They are part, together with the actual print preview of a large control: TdxPSPreviewWindow.

As it happens, the TdxPSPreviewWindow can be drawn without the surrounding controls. They are superfluous in my case. After a lot of testing and studying I finally made it to the following window look:

[attachment=8345:DevExprPrPreviewFinal.jpg]

As you can see, the only dissonant now is the TcxSpinEdit control. It would only be skinned correctly if the ThirdParty list would allow for the addition of a control with a SpinEdit type of skin. Would that be a big problem to make?

[HeDiBo]

'Support' wrote:

I think, not all controls were added in the ThirdParty list.

These controls are standard? TStatusBar used there?

The bar below the main menu is a standard TToolbar. The controls on the toolbar that are skinned wrong are a TcxComboBox and a TcxSpinEdit. I thought these would be skinned by acLFPainter if environment variable DEVEX2011 was set.

The TcxComboBox could be added easily to ExternalControls as ComboBox. That did the trick.

Adding TcxSpinEdit as an UpDownBtn does not make it look better (different, but not better).

The controls beneath the toolbar are a whole different cup of tea. They are part, together with the actual print preview of a large control: TdxPSPreviewWindow.

[HeDiBo]

'Support' wrote:

All skins have a list of mandatory sections like 'EDIT', 'BUTTON', etc (main sections) and list of sections which may not exist in a skin.

If auxiliary section doesn't exists, then main section used instead.

I know a common solution for your issue, I will add a checking for unexisting sections at the skin loading and such sections will be added in run-time automatically, but time is required for that.

This issue will be solved in the nearest release.

When skins lack the TB_BTN section, what section do you use for TitleBar buttons from TsTitleBar? (I thought the TB in TB_BTN stood for TitleBar.)

[HeDiBo]

I noticed in Print Preview that the second bar from the top is not skinned at all:

[attachment=8341:PrPreviewBar.jpg]

This missing of skinning is also true for the status bar at the bottom.

Also notice that the font color for percentage is wrong, making it unreadable.

[HeDiBo]

'Support' wrote:

The ChangeSysColors property changes system colors in all application.

If some controls uses system color, like clWindowText, then this color will be received from skin and we can't change it.

I think, you can try to use clBlack instead of clWindowText. Color will be clBlack always in this case.

Great That did the trick

[HeDiBo]

'Support' wrote:

Hello, thank you for screenshots and code.

Can you upload the Dfm-file for this form also, please?

I will try to make a test-application based on this Dfm.

SkinManager have default options specified?

Sending the DFM file will not help you much. That's almost empty. All dfm info is in the frames that make up the tab sheets.

I'll send some files by private mail to you.

[HeDiBo]

I changed the main form to get rid of the row of speedbuttons at the bottom and make the page control show the tab labels again.

That cured the problem.

I'm not happy with that. It means that selecting a tab sheet with sPageControl.ActivePage := some_tab becomes different from selecting that tab manually with the tab label. The former may cause all sorts of problems!

Also, that makes this bug: http://www.alphaskin…?showtopic=9581 even more important to fix.

[HeDiBo]

No change in AC 12.11 (not that I expected it so soon already )

[HeDiBo]

'HeDiBo' wrote:

Although OnActivate is now called only on activation, OnDeActivate is not called when the SkinManager is destroyed. Allocations in OnActivate will leak memory when SkinManager is destroyed.

Don't put too much effort into this. It's really a very minor detail.

[HeDiBo]

'Support' wrote:

This behaviour will ne changed in the next release.

Although OnActivate is now called only on activation, OnDeActivate is not called when the SkinManager is destroyed. Allocations in OnActivate will leak memory when SkinManager is destroyed.

[HeDiBo]

'HeDiBo' wrote:

Another solution might be to add bGlyphCentered to the Layout property.

That would also give the possibility of a transparent image in the middle with texts on both sides

[HeDiBo]

'Support' wrote:

Wow, thank you for the demo, I will research it.

Somewhere, sometime, the bug is solved (AC 12.10)

[Author]

Posts