Log in to start a topic

Issues found testing with 8.0.20241.664

Posted by: abraham on 16 August 2024, 2:21 am EST

  • abraham

    • Post Options:
    • Link
      Copy

    Posted 16 August 2024, 2:21 am EST - Updated 16 August 2024, 10:24 pm EST

    Doing new evaluations of the C1 Input v 8 controls to assess the viability of upgrades of legacy .NET 4.8 projects, we discovered the current v 8 (8.0.20241.664) C1 input controls have two annoying issues that should be fixed somehow.

    Issue 1)

    Adding the C1.Win.DbNavigator to a project that already has C1.Win.Input, C1.Win.Calendar, C1.Win.TrueDBGrid, C1.Win.FlexGrid added, causes the designer to choke: the C1TextBox control is not visible anymore in the Toolbox panel and any existing on-form C1TextBox controls cannot be edited with the Form designer anymore. See two example solutions below that demonstrate this problem.

    Issue 2)

    Setting the DataSource + DataMember for e.g. C1TextBox / C1DateEdit / C1Label to an on-form BindingSource and a named member/field/column, but with the BindingSource itself still unconnected to an underlying DataTable/DataView/BindingList, the appropriate init code for InitializeComponent() is generated. However when the application is run, the C1 Input controls throw exceptions because the BindingSource is still unconnected/empty at the time InitializeComponent() is run - that happens only after that call in the remainder of de Form Constructor code.

    C1 controls like C1FlexGrid or C1TrueDBGrid don’t have this problem, so this would be easy to fix: do not throw exceptions when the DataSource for the controls is still empty.

    It should be noted standard .NET controls like TextBox also do have the this capability of a DataBinding to a named field/member/column for a BindingSource that doesn’t have a DataSource set yet at design-time. So fixing this issue for the C1 Input controls would bring it in line with the standard .NET controls.

  • abraham

    Posted 16 August 2024, 2:25 am EST - Updated 16 August 2024, 2:27 am EST

  • uttkarsh.matiyal

    Posted 19 August 2024, 2:18 am EST

    Hello,

    Thank you for providing the samples. We were able to replicate the following two of the behaviors:

    1. Input controls are not visible in Toolbox after installing DBNavigator. [Internal Tracking ID: C1WIN-32788]
    2. C1TextBox and C1Label are not editable / VS deadlocks. [Internal Tracking ID: C1WIN-32789]

      We have escalated these behaviors to the development team to get further insights. Rest assured we’ll update you once we get any information.

    We are sorry, but we could not replicate issue 2, where setting the DataSource + DataMember for C1Input controls results in an exception in the designer using your instructions in the sample attached (uncomment these next two lines + set these properties using the Winforms Designer to reproduce the exception).

    To replicate the behavior, we tried to create a sample project and set DataSource + DataMember with empty binding source and got the following error:

    System.ArgumentException: 'Cannot bind to the property or column city on the DataSource. (Parameter 'dataMember')'

    We have escalated this behavior to the development team for further investigation. [Internal Tracking ID: C1WIN-32790]

    Please let us know if you are also getting the same error.

    Regards,

    Uttkarsh.

  • abraham

    Posted 19 August 2024, 2:45 am EST

    @uttkarsh.matiyal:

    Issue 2) is a run-time error as indicated in the text; the exception you mention is the correct one for that. It shouldn’t occur for controls bound to a BindingSource that still has an unbound DataSource itself at the time InitializeComponent() is run.

    Looking forward to updates from the dev team.

  • uttkarsh.matiyal

    Posted 20 August 2024, 12:03 am EST

    Hello,

    As per the development team,

    • C1WIN-32788 and C1WIN-32789 : These issues have been fixed and will be available in the upcoming release. (2024 v1 hotfix 2)
    • Thank you for the confirmation on “issue 2”; we’ll let you know once we have updates from the development team on this behavior.

    Regards,

    Uttkarsh.

  • abraham

    Posted 20 August 2024, 12:17 am EST

    @uttkarsh.matiyal:

    That’s good news.

    For issue 2) it’s important the behaviour of the C1 Input controls is brought in line with the standard .NET controls (e.g. TextBox) and the C1FlexGrid and C1TrueDBGrid controls - these all behave correctly when bound to BindingSource members/fields/columns where the BindingSource is still unbound itself.

    Consistency across .NET and C1 controls is essential.

  • uttkarsh.matiyal

    Posted 21 August 2024, 3:25 am EST

    Hello,

    As per the development team, the issue-2 you reported is a bug and ETA for the fix is 2025v1.

    [Internal Bug ID: C1WIN-32799]

    Rest assured, we’ll update you once the issue has been fixed.

    Regards,

    Uttkarsh.

  • abraham

    Posted 22 August 2024, 8:07 pm EST

    Wonderful, looking forward to the fixes.

  • uttkarsh.matiyal

    Posted 25 October 2024, 8:12 am EST

    Hello,

    We are glad to let you know that both C1WIN-32788 and C1WIN-32789 issues have been fixed in the 2024v1 hotfix 2. You can update your nuget packages to the latest version (8.0.20241.672) to resolve the issue.

    We’ll update you once your last issue is also fixed.

    Regards,

    Uttkarsh.

  • abraham

    Posted 25 October 2024, 11:11 am EST - Updated 25 October 2024, 11:11 am EST

    Thanks, will test asap … !

  • abraham

    Posted 18 February 2025, 7:15 am EST

    Any news on the resolution of this Internal Bug ID: C1WIN-32799 ? Is that still forecast for the 2025 v1 update?

  • abraham

    Posted 18 February 2025, 8:53 am EST

    I received an email reply related to this thread, but the reply does not appear on the forum thread. The fix for issue-2 as describe in my original posting and further explained in the thread is essential to bring the C1 components in line with standard .NET controls behaviour. Without that fix we can’t use the designer to link C1 controls to a BindingSource that hasn’t got a DataSource itself yet at runtime when a Form’s InitializeComponent() is called. Normally the BindingSource’s DataSource will be set AFTER the InitializeComponent() call in the Form constructor.

    It’s a simply fix really - C1 controls should not throw an exception when they’re instantiated and configured during InitializeComponent() when the connected BindingSource DataSource is still empty. I could do it myself if the code was open source.

  • uttkarsh.matiyal

    Posted 19 February 2025, 10:46 pm EST

    Hello,

    We’ve tested the latest version of the control, and the issue has been resolved. Although the team initially expected the fix to appear in the 2025v1 release, it was actually implemented and released ahead of schedule.

    We understand that while some issues might seem simple to fix, we need to fully test every change to ensure it doesn’t introduce new problems. Thorough testing and QA take time, and we truly appreciate your patience and cooperation.

    The issue is fixed and released in the 2024v2 Hotfix1-693 build. Please upgrade the version to resolve the issue.

    Regards,

    Uttkarsh.

  • abraham

    Posted 6 March 2025, 11:43 pm EST

    I’ve just conducted a renewed evaluation of C1 Winforms version 8.0.20242.700 (latest), and indeed, the bugs I reported in August 2024 have been fixed. We’ll deepen our evaluation and hopefully this release might finally enable us to migrate from .NET 4.8 to .NET 9 …

  • uttkarsh.matiyal

    Posted 9 March 2025, 11:33 pm EST

    Hello,

    We’re glad to know that the issues you reported are fixed.

    If you require any further assistance or have any questions, please do not hesitate to reach out to us. We’re closing this ticket for now. Rest assured, you can open this ticket anytime by reverting, or you can create a new ticket if you have a different concern.

    Regards,

    Uttkarsh.

  • abraham

    Posted 12 March 2025, 10:20 pm EST - Updated 12 March 2025, 10:55 pm EST

    We’ve gone to the next step in our .NET 4.8 > .NET 9 upgrade efforts, and run into the same issue as reported here:

    https://developer.mescius.com/forums/winforms-edition/c-windows-form-view-designer-showing-error#67255

    For forms that have an existing (.NET 4.8 era) C1TrueDbGrid - as soon as the designer tries to open that form, the error mentioned is shown. The support staff in that thread mentions a Case nr, but the fix isn’t publicly posted. Any suggestions?

    Edit: find a public suggestion here:

    https://developer.mescius.com/forums/winforms-edition/c1dashboardlayout-samples-designer-does-not-work-in-net-8#76765

    But I would plead for a proper public migration guide instead of having to look everywhere for suggestions …

  • uttkarsh.matiyal

    Posted 13 March 2025, 12:42 am EST

    Hello,

    We have replied to the other case.

    The reported behavior is a bug in the product samples and will be fixed by the next release. [Bug Tracking ID: C1WIN-32852]

    Regards,

    Uttkarsh.

  • abraham

    Posted 13 March 2025, 1:18 am EST

    The bug also occurs when upgrading our own .NET 4.8 era code - it’s probably best if the suggested fix is part of the migration guide to the C1 .NET 6/7/8/9 components. Others will experience the same issue.

  • uttkarsh.matiyal

    Posted 17 March 2025, 1:42 am EST

    Hello,

    We created a simple sample with C1DashboardLayout in .NET Framework 4.8 and upgraded it using the .NET Upgrade Assistant tool (https://learn.microsoft.com/en-us/dotnet/core/porting/upgrade-assistant-overview) but could not observe the designer error.

    Furthermore, as per the team, the issue is only present in the C1 samples.

    Sample: DashboardLayout_Sample.zip

    Please let us know if we’re missing something here or if our understanding differs.

    Regards,

    Uttkarsh.

  • abraham

    Posted 17 March 2025, 7:53 am EST

    Hi,

    The designer exception issue only occurs if the .NET 4.8 era form with a C1TrueDbGrid on it has a .resx file with the following property for the C1TrueDbGrid instance:

    <data name="<gridname>.PrintInfo.PageSettings" mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
        AAEAAAD ....

    Removing the element from the form’s .resx file and the associated call in the InitializeComponent() like:

    this.<gridname>.PrintInfo.PageSettings = ((System.Drawing.Printing.PageSettings)(resources.GetObject("<gridname>.PrintInfo.PageSettings")));

    will solve the problem - the designer then opens the form normally.

    So if the .NET 4.8 C1TrueDbGrid doesn’t have that PrintInfo.PageSettings property set in the .resx file, the exception would not occur, but otherwise it does. We have legacy projects with literally 10’s of forms with a C1TrueDbGrid component - and we can confirm the above procedure solves it.

  • uttkarsh.matiyal

    Posted 18 March 2025, 5:30 am EST

    Hello,

    The entry in resx file was made by TrueDBGrid in older versions. Now due to change in the design and architecture, this entry is no longer used and can be removed.

    Regarding mentioning this change in migration guide, you can refer to the following comment on your other Forum thread:

    https://developer.mescius.com/forums/winforms-edition/c-windows-form-view-designer-showing-error#79589

    Regards,

    Uttkarsh.

  • abraham

    Posted 19 March 2025, 11:44 pm EST

    Another migration related issue/question:

    In the C1 Winforms suite .NET 4.8 version, C1TextBox inherits from TextBox (and indirectly from Control), and a tooltip could be set for a C1TextBox named ‘c1TB_Name’ with:

    ToolTip toolTip = new ToolTip();
toolTip.SetToolTip(this.c1TB_Name, "Name");

    With the .NET 6+ version of the C1TextBox control this no longer works. The code above compiles and runs, but the tooltip never gets displayed on the C1TextBox control.

    How to get this working? I realise C1TextBox in the .NET 6+ verion doesn’t inherit anymore from TextBox, but it does still inherit indirectly from Control.

    Our LOB apps rely heavily on ToolTips so at the moment this is a showstopper in the migration.

  • uttkarsh.matiyal

    Posted 21 March 2025, 2:23 am EST

    Hello,

    The new TextBox is implemented on XViewLight, which exposes some protected methods and properties to implement tooltips using internal C1SuperToolTip. This ensures a consistent look between the tooltips associated with XView elements and other controls on your form.

    Methods:

    • protected void SetToolTip(Control control, string text)
    • protected string GetToolTip(Control control)
    • protected void UpdateToolTip()
    • protected void HideToolTip()

      Properties:
    • protected bool ShowToolTips
    • protected C1SuperTooltipBase SuperTooltip
    • protected C1SuperTooltipBase InnerTooltip
    • protected C1SuperTooltipBase EffectiveTooltip

    We have created a simple sample for the same: TextBox_ToolTip.zip

    Refer to C1SuperTooltip documentation for more information: https://developer.mescius.com/componentone/docs/win/online-supertooltip/overview.html

    Regards,

    Uttkarsh.

  • abraham

    Posted 21 March 2025, 4:29 am EST

    Thank you, that is very helpful. I had great difficulty finding documentation for that from the C1TextBox docs. Maybe good to improve some of the docs cross-links and present a similar example as well in the docs.

    Thanks again.

  • uttkarsh.matiyal

    Posted 24 March 2025, 8:09 am EST

    Hello,

    We have forwarded your concerns to the concerned team for further insights and will update you once we have more information. [Internal Tracking ID: C1DOC-10142]

    Regards,

    Uttkarsh.

  • abraham

    Posted 24 March 2025, 8:47 am EST

    Wonderful, further question on the new .NET 6+ C1DateEdit control. In the .NET 4.8 version this control had a ‘Modified’ property, but this property is missing in version 8 … any suggestions on a replacement for that?

  • uttkarsh.matiyal

    Posted 25 March 2025, 1:49 am EST

    Hello,

    We were able to observe the same. We have shared your concerns with the development team for further insights and will update you once we have more information. [Internal Tracking ID: C1WIN-33813]

    Regards,

    Uttkarsh.

  • abraham

    Posted 25 March 2025, 2:25 am EST

    Thanks, it’s quite an essential property, so I will anxiously await any updates. It’s essential for our LOB platform migration.

    Interestingly, C1TextBoxBase (parent class for C1TextBox, C1MaskedTextBox and C1NumericEdit) does have the Modified property in the version 8, so it looks as it may have been overlooked in the .NET 6+ versions. An update for C1DateEdit to make it consistent with C1TextBoxBase (version 8) and backward compatible with the .NET 4.8 version of C1DateEdit would be logical and solve many migration issues.

    Looking forward to more news. Thanks in advance!

  • uttkarsh.matiyal

    Posted 26 March 2025, 12:08 am EST

    Hello,

    Thank you for the additional information.

    The “Modified” property is included in C1.Win.Input.Base.C1TextBoxBase class; however, in .NET 6/8, C1DateEdit is not inherited from C1.Win.Input.Base.C1TextBoxBase class. For further insights on this, we have escalated it to the development team. Rest assured, we’ll update you once we have more information.

    To avoid misunderstandings and ensure better tracking of issues, we’d recommend creating separate query tickets for different concerns.

    Regards,

    Uttkarsh.

  • uttkarsh.matiyal

    Posted 8 April 2025, 2:30 am EST

    Hello,

    As per the team, currently there is no Modified property in .NET Core, but as a workaround you can subscribe to the ValueChanged event or override OnValueChanged(), updating a custom “Modified” property as follows:

    public class MyDateEdit : C1DateEdit
{
    [DefaultValue(false)]
    public bool Modified { get; set; }
    protected override void OnValueChanged(EventArgs e)
    {
        base.OnValueChanged(e);
        Modified = true;
    }
}

    Please refer to the attached sample for implementation. (see DateEdit_Modified.zip)

    The team is currently discussing whether to include this property in .NET 6/8 in upcoming versions. We’ll keep you posted as soon as we have more information on this.

    Regards,

    Uttkarsh.

  • abraham

    Posted 8 April 2025, 3:46 am EST - Updated 8 April 2025, 4:09 am EST

    Thanks, we’ll try that workaround for now … for future releases it would be very helpful to have the Modified property available for the C1DateEdit … it provides consistency with the other C1 Input controls and with the previous .NET 4.8 version. Will let you know how we fare with your workaround recommendation.

    Update: in your example the Modified property changes every time the underlying value changes. But that is not how the property behaved in .NET 4.8 and how it behaves for the other Input controls (C1TextBoxBase).

    The documentation for the ‘Modified’ property for .NET 4.8 for the C1TextBox states:

    Modified Property (C1TextBox)

    Gets or sets a value that indicates that the control has been modified by the user since the control received the input focus or its Value last set.

    (the docs for the C1TextBoxBase Modified property for the .NET 6+ version states the same)

    That’s exactly what we need: we use this property to track UI/user triggered changes, but in your example when e.g. the C1DateEdit value is bound to a BindingSource that is connected to a list or DataView, and the user changes item/row position - the value of the C1DateEdit will change and subsequently the Modified property is set to true (which is not desirable).

    Also e.g. at BindingSource PositionChanged event or when the underlying DataRow is saved via ADO.NET the Modified property should revert to false again.

    To summarise: it’s not the change of the bound value that should set this property to true, but only a user initiated modification since its value was last set. I could try another workaround myself, but I think this observation highlights the need for a proper implementation to bring it in line with the other C1TextBoxBase controls.

  • abraham

    Posted 9 April 2025, 3:27 am EST

    In the meantime, we’ve taken your custom sub-class suggestion fix and converted that into something usable for the detection of a change in the Value property as a result of user interaction (the exposed event ‘ValueChangedByUser’ does not fire from DataSource updates - so that’s an improvement relative to your sample).

    It’s not a full equivalent to a ‘Modified’ property as the ValueChangedByUser will not fire when a user is still halfway editing. However it’s better than nothing.

    See the attached sample solution for the sub-class and a demo.

    Doing this customisation we also run into two bugs of the current C1DateEdit version (these are also demoed in the sample):

    1. when a C1DateEdit’s initial Value is DBNull.Value, and a user uses the dropdown calendar to select ‘today’ - the DateValueSelected event does not fire - while it should.
    2. when a C1DateEdit’s initial Value is set to a certain Date(Time) that is not today - upon opening of the form, the C1DateEdit control instantly fires the DateValueSelected without any user interaction at all - I assume that is not intended.

    The customised, extended WI_C1DateEdit, also suffers from bug 1) but is shielded from bug 2) because in its DateValueSelected it checks if the control is actually in dropdown mode. Doing so would also provide protection for bug 2) but I’m sure that is not the intended behaviour.

    WI_C1DateEdit.zip

  • uttkarsh.matiyal

    Posted 10 April 2025, 2:21 am EST

    Hello,

    Thank you for your feedback on the “Modified” property and apologies for overlooking the use case of the property you mentioned. We’re glad to know that you were able to modify the workaround as per your needs.

    Behavior regarding DateValueSelected event:

    We were able to observe the behavior at our end as well, thus escalated it to the development team for further insights. [Internal Tracking ID: C1WIN-33905]

    In your customised, extended WI_C1DateEdit, you can override OnValueChanged() instead of OnDateValueSelected() to counter behavior 1). Please refer to the attached sample for the same (see WI_C1DateEdit_WA.zip) and let us know if it works well for all of your scenarios.

    Suggestion: The current thread has grown quite large, which may make it difficult to keep track of all the issues and might lead to confusion—for you or anyone else involved. To avoid misunderstandings and ensure better tracking of issues, we suggest creating separate query tickets for different concerns.

    Regards,

    Uttkarsh.

  • uttkarsh.matiyal

    Posted 14 May 2025, 12:33 am EST

    Hello,

    Regarding C1WIN-33905,

    As per the team, the reported issue is a bug and the ETA for the fix is the 2025v2 release.

    [Bug Tracking ID: C1WIN-34024]

    Regards,

    Uttkarsh.

  • abraham

    Posted 14 May 2025, 1:01 am EST

    Thanks, looking forward to that. The most urgent bugs/issues we are awaiting fixes for are:

    C1TextBox + C1DateEdit: [Internal Tracking ID: C1WIN-34001]

    C1DbNavigator: [Internal Tracking ID: C1WIN-34016]

    Primarily the first one is blocking us from deployment of a big already migrated LOB project. Any ideas what the time frame for a possible fix might be?

  • uttkarsh.matiyal

    Posted 14 May 2025, 3:15 am EST

    Hello,

    We’ll update the mentioned issues on their respective tickets as soon as we get updates from the development team.

    Thank you for your understanding.

    Regards,

    Uttkarsh.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © 2023 MESCIUS USA, Inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.