[HeDiBo]

'Support' wrote:

Thank you for the demo, I will fix it soon.

Problem solved in 12.14

[HeDiBo]

'HeDiBo' wrote:

I notice now that I did not make it clear, this bug only appears at design time. When I run the application it's not a problem,

If you still want a complete application to view this problem, let me know.

Solved in 12.14

[HeDiBo]

'Support' wrote:

Hello

Easiest way will be changing a width of button to 0, I think (declared as private).

Look attached demo, it was tested with Delphi 7 only.

Thanks for your suggestion.

Unfortunately it only works if the TsDBLookupCombo is not skinned. If you clear the SkinSection in the SkinData property and add a skinmanager and skinprovider, it doesn't work anymore.

PS. I didn't know you could fill in something like TSDBLOOKUPCOMBOBOX in the skin section. I assume anything not predefined turns skinning off.

[HeDiBo]

'Support' wrote:

Unfortunately, I can't repeat an issue with invisible button and with changed tab font.

Your Dfm-file doesn't help. Maybe you can make a test-app based on this form later?

I notice now that I did not make it clear, this bug only appears at design time. When I run the application it's not a problem,

If you still want a complete application to view this problem, let me know.

[HeDiBo]

'Support' wrote:

I have researched this issue and see that big changes required for changing of this behavior.

Control should be rewritten and I'm planning to do it in the next Beta version (12.20).

As a quick solution, I think you should make a bigger width of control, maybe for 3-4 pixels will be enough.

With a width of 50 it worked OK.

You already said that's a bug, so I will test it again in 12.20

Thanks for the quick fix.

[HeDiBo]

Problem is still there in 12.13

[HeDiBo]

'Support' wrote:

Fixed now, changes will be available in the nearest release.

Problem is not solved in 12.13

Here is a test project showing it:

[attachment=8394:acRoundBtnDisabledBug.zip]

[HeDiBo]

'Support' wrote:

PS. I can repeat it and I will fix it soon, thank you.

I found that if the SkinManager is not present, it goes OK.

But if the SkinManager is present but not active, it goes wrong.

PS. Do you ever sleep??

[HeDiBo]

'HeDiBo' wrote:

That's difficult. It only occurs the first time the window is shown, not after that.

I'll have a look further into this. I know for example, that the SpinEdit value is changed programmatically also. Maybe there's a cause for this behavior.

I found it has nothing to do with clicking up or down.

This is how the spinedit looks when changing other settings has enabled it and given it Value 1:

[attachment=8379:spineditbug01.jpg]

Then I click the mouse on the value 1, without touching the up or down arrows. Just placing the cursor in the value field:

[attachment=8381:spineditbug02.jpg]

And as you can see, it is already distorted

[HeDiBo]

'Support' wrote:

I mean a space between content of (text) and borders of the control.

Text will be shifted inside the control if padding is specified.

I understand. You do not mean the distance between the label and the control, but the height of the bounded label itself. Very nice, but you must remember its height. If the label is set to the left of the control and then placed back again at the top it should still use the last height / padding.

[HeDiBo]

'Support' wrote:

I think, the Padding property may be added in labels (like a padding in CSS – Left, Top, Right and Bottom).

We will be able to shift a text within the label and label may be aligned in this case…

With Padding, you mean adding space between the label and the component? Because that's already there (It's called Indent). So, I suppose you mean something else?

[HeDiBo]

'Support' wrote:

Can you check if some event have influence to this behavior and which code can help to repeat it?

That's difficult. It only occurs the first time the window is shown, not after that.

I'll have a look further into this. I know for example, that the SpinEdit value is changed programmatically also. Maybe there's a cause for this behavior.

[HeDiBo]

'Support' wrote:

Hello

Do you handle any events in this control?

Yes: OnDownClick, OnUpClick and OnExit

[HeDiBo]

'HeDiBo' wrote:

The TsSpinEdit that I use in my project looks wrong for the Jeans skin.

This is what happens: the window shows and I click the Up Arrow. Now the text becomes unreadable. Every next time this spinedit shows, it looks OK.

This is what it looks like the first time:

[attachment=8377:SpinEditJeans.jpg]

This is how it looks in the Notes Leather skin:

[attachment=8378:SpinEditLeather.jpg]

When I switch away to another application and go back, everything is OK again.

I now found out it is wrong in other skins too.

I tried to build a test project, but cannot get it wrong then .

[HeDiBo]

'Support' wrote:

Thank you, I see now.

I need to think how to implement it, because some difficulties exists.

For example, if Layout is sclLeftTop and if label aligning is working then it's hard to align a text to the top. The offset property will be ignored in this case.

I hope you understand what I mean.

The Offset property must be added to the Label control in this case, many code must be rewritten.

I totally understand. I thought, because when the component is aligned alLeft and the BoundLabel.Layout = sclLeft, the label's width and offset are honored, that BoundLabel.Layout = sclTopLeft would require similar coding. Apparantly it's more complex.

Is this an idea: All components having a BoundLabel property, are placed inside an invisible but alignable container. That container copies the properties of the original component. Then if the component itself is, say, aligned left, the container is aligned left. If the label has the topleft layout, the component is aligned at the bottom of the container, the label is aligned at the top and the height of the container is the height of the component + the height of the label + the offset. If the label has the sclLeft layout, the component is aligned right in the container and the label is aligned left. The width of the container then is width of label + offset + width of component.

In other words, alignment, positioning and size are governed by both the component and the label, without the user knowing any of this.

It is just an idea. May be it's totally foolish and useless.

[HeDiBo]

'Support' wrote:

Hello!

Please, check attached files, something is wrong there, seems.

Don't know what happened. This is the correct file:

[attachment=8375:acBoundLabel.zip]

[HeDiBo]

'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.

[HeDiBo]

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

[HeDiBo]

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

[HeDiBo]

'Support' wrote:

This skin exists there. Maybe you have downloaded this archieve before he was updated…

That must have been it then

[Author]

Posts