A skinned version of DevExpress Print Preview is wrong

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #37493
    HeDiBo
    Participant

    With sSkinManager.Options.ChangeSysColors set to True, a print preview of the DevExpress Printing System looks like this (skin is Cappuccino):

    [attachment=8320:DevExprPrPreview.jpg]

    Suddenly some components become partly skinned (3 x TsDBText and 2 x TsStickyLabel are placed on a normal TPanel and a standard TListView placed directly on the form)

    When sSkinManager.Options.ChangeSysColors is set to False it looks OK:

    [attachment=8321:DevExprPrPreviewOK.jpg]

    Setting ChangeSysColors to False is not a good solution, because “Save As” and similar standard dialogs don't look good then.

    #56756
    Support
    Keymaster

    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.

    #56767
    HeDiBo
    Participant
    '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 a3.gif That did the trick

    #56768
    HeDiBo
    Participant

    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.

    #56784
    Support
    Keymaster

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

    These controls are standard? TStatusBar used there?

    #56785
    HeDiBo
    Participant
    '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.

    #56791
    HeDiBo
    Participant
    '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?

    #56811
    Support
    Keymaster
    'HeDiBo' wrote:
    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?

    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.

    #56814
    HeDiBo
    Participant
    '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.

    #56848
    HeDiBo
    Participant

    I'm still having problems with the print preview window.

    This is how it looks in the Notes Leather skin:

    [attachment=8360:PrintPreviewOK.jpg]

    That's the way it should look. But in the Jeans skin it looks like this:

    [attachment=8359:PrintPreviewERR.jpg]

    That's definitively wrong. The preview looks skinned like containers in general. This screen shot of the Demo program shows the same skinning:

    [attachment=8361:PrintPreviewSimilar.jpg]

    These are the units used to display the preview and the base for all prints:

    [attachment=8362:dxPrinting.zip]

    I'm really searching for a way to disable the skinning of the TdxfmStdPreview component, but after days of research, I still don't see any light.

    I surely hope you can shed some light on this wacko.gif

    #56849
    HeDiBo
    Participant

    I managed to build a test project, that shows the trouble:

    [attachment=8364:acPrintPreview.zip]

    Before you click the Preview button, you can change the skin to see the effect as it should be. The program starts in the Jeans skin, which shows the problem.

    Interesting thing: when you change the skin, after you have seen the print preview, the print preview stays exactly the same: if it was wrong before, it stays wrong, if it was OK before it stays OK wacko.gif

    #56088
    Support
    Keymaster

    Thank you for the demo.

    I have installed DevExpress and checked your project now.

    So, clWindow color is uses in the preview area. If the SkinManager.Options.ChangeSysColor property is True, then this color is replaced by color of edit fields from current skin.

    When TfrmPrintBasis is created, then this color is saved in this object and used later when preview is shown. If skin is changed and this object is destroyed and created again, then this variable is reinitialized.

    I have no idea how to change this behaviour at the moment.

    #56080
    HeDiBo
    Participant
    'Support' wrote:

    So, clWindow color is uses in the preview area.

    I think DevExpress made the wrong choice here. Because Preview should mimic a later print-out, the preview area should be clWhite, not clWindow.

    Can you tell me where in the DevExpress source you found this color assignment. If you can tell me that, I think I will change it then and notify DevExpress of this error.

    #56054
    Support
    Keymaster

    Sorry, I can't find it quickly there, the package is huge.

    But I'm sure – clWindow color used there.

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.