ColorDialog not on top of Main Form

Hi Dinko,

Thanks for your response on this.

I thought I might try use your example to see if I can replicate it, and I found the same issue straight away..



I get the same issue restarting Visual Studio at 100% scaling

The system ColorDialog works as expected

More info:

Is there any other info you might need from me?

this.TopMost = true;

TopMost = false

It seems I can work with the Color Dialog as long as I dont use TopMost or set these to false when I need the Dialog, but it seems like I should not be doing this.

Having played with this control...

I found 2 more issues:

1) The scaling is all wrong withing the Dialog, ie I cannot see all the RGB values (see screen shot below)

I have 2 x 4K monitors at 150% and my laptop screen at 150%, the dialog should cater for this.

2) When setting the OldValue, the colour is not being set correctly. Old COlour is Blue

Thank you for the provided images.

For the TopMost property: I have doubled check my project and you are right the RadColorDialog is placed under the form if the form is TopMost. It seems that I have overlooked it at first. It took me some time to investigate why this is happening. It turns on it is not directly related to our controls. You mentioned that you are using .Net7. I have tested it with .NetFramework 4.8 and this behavior is not observed. Our RadColorDialogs derives from MS CommonDialog which seems to be the problem. I have created a simple class that derives from this one and the dialog is not on top.

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        TopMost = true;
    }

    private void button1_Click(object sender, EventArgs e)
    {
        new MyCommonDialog().ShowDialog();
    }
}
public class MyCommonDialog : CommonDialog
{
    private Form myForm = new Form();
    public override void Reset()
    {
    }

    protected override bool RunDialog(nint hwndOwner)
    {
        return ((Form)myForm).ShowDialog(NativeWindow.FromHandle(hwndOwner)) == DialogResult.OK;
    }
}

This behavior is not directly related to our controls, but to the MS CommonDialog which the RadColorDialog derives from. To workaround this behavior, you can set the TopMost property of the RadForm inside the RadColorDialog.

private void radButton1_Click_1(object sender, EventArgs e)
{
    (radColorDialog.ColorDialogForm as RadForm).TopMost= true;
    radColorDialog.ColorDialogForm.OldColor = Color.Bisque;
    radColorDialog.ShowDialog();
} 

As for the other questions, you are right the RadColorDialog elements location is messed up when the monitor that main form where the applications start has a higher DPI than 100%. I have searched our backlog and found that this behavior is already logged. You can follow the item to receive status changes so that you can be aware of its progress.  I have added your scenario to the feedback and increased its priority so that our team could consider adding this to their planning.

Regarding the OldColor property. Upon testing this, the property is set correctly. Can you share how you are setting this property?

Hi,

ok thanks for your replies.

For the TopMost issue, I can get around that.

The OldValue is ok, it makese sense now on how that works, I can set the SelectedValue to pick the last one anyway.

Given the scaling issue, we cannot use the control until that is fixed, hopeully this is fixed soon

I am sorry to hear that this behavior is stopping you from using the control. I have already forwarded this behavior to our development team and raised the priority of the item. When the feedback item is planned for fixing, we will update the status of the item so that you can be notified.

In the meantime, if you have any other questions, feel free to open a new thread with your questions and we will be happy to help.

Upon checking the feedback item, which I forgot to share in my previous post, accept my apologies for that, is currently not planned for fixing. If you haven't done it already, you can subscribe to the feedback item so that you will be notified of its status change. 

In the meantime, if you have any other questions, feel free to open a new thread, and will be happy to help.

Sorry I was referring to this issue:

"You are right that supporting different scaling is an important functionality for user-friendly applications. I will let you know when this behavior is added to our development team planning for fixing."

The component is useless if the monitor is not set to 100% scaling?

This is a fundamental bug.

Hello, Mark,

I understand the importance of this issue and that it affects your application. The feedback item has already been marked with increased priority in our internal issue tracking system. However, I can't give you an exact time frame when a fix would be introduced. If disabling the scaling is a valid approach for you feel free to disable it.

Please excuse us for the inconvenience caused.