Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for "UserControl" Containers #339

Closed
wants to merge 2 commits into from

Conversation

nfasvp
Copy link

@nfasvp nfasvp commented Feb 20, 2022

  • Enhancements:
    • Added support for "UserControl" Containers

      • Previous versions only supported placing controls like MaterialDialog if the Parent Container was of a type that inherits from Winform (Form class), like MaterialForm or plain Winform. Adding MaterialDialog control to a custom UserControl would generate a runtime exception because MaterialDialog._formOverlay was expecting an "Onwer" of type "Form" which is not the case when using parent containers like UserControls.
      • Changed class "MaterialDialog" to expect a Parent-container of type "ContainerControl", Form and UserControl classes inherit from ContainControl class.
      • Affected files:
        • MaterialDialog.cs
        • MaterialSkinManager.cs
    • Improved design-mode experience of MaterialDrawer when combined with MaterialTabControl object. Now, during design-time, it's possible to view the drawer and the design impact on it when drawer's and tabcontrol's properties are changed by the user.

      • Design-Mode Before:
        image

      • Design-mode After:
        image

    • Improved performance of MaterialDrawer during initialization

      • Reduced the number of "Redraws" (Pain events) while the MaterialDrawer control is being initialized by its container.
        • Previously, during MaterialDrawer's initialization, every property set done by the container that would impact drawer's UI would generate a redraw event (paint event).
        • Now, MaterialDrawer control checks if its container has finished the initialization and if not ignores the redraw. When container invokes control's "InitLayout" method, meaning "end of control's initialization phase, future propertities changes will invoke a redraw action.

Nuno Pereira added 2 commits February 20, 2022 11:36
-------------------------
  - Code Cleansing:
    - moved all p/invoke declarations to a new static class "NativeWin" (NativeWin.cs)
      - there were a significant number of duplicated declarations on several controls
      - affected files:
        - NativeTextRenderer.cs
        - MouseWheelRedirector.cs
        - MaterialDialog.cs
        - MaterialForm.cs
        - MaterialMultiLineTextBox.cs
        - MaterialMultiLineTextBox2.cs
        - MaterialScrollBar.cs
        - MaterialSnackBar.cs
        - MaterialTextBox.cs
        - MaterialSkinManager.cs

    - moved several const declarations related to native Window Message IDs to new static class "NativeWin"
      - affected files:
        - MouseWheelRedirector.cs

    - moved all possible category's labels to a new static class "CategoryLabels" (Globals.cs) and replaced the Category Labels by the corresponding const string
      - affected files:
        - MaterialButton.cs
        - MaterialCheckBox.cs
        - MaterialComboBox.cs
        - MaterialDrawer.cs
        - MaterialExpansionPanel.cs
        - MaterialFloatingActionButton.cs
        - MaterialForm.cs
        - MaterialLabel.cs
        - MaterialListBox.cs
        - MaterialListView.cs
        - MaterialMaskedTextBox.cs
        - MaterialMultiLineTextBox.cs
        - MaterialMultiLineTextBox2.cs
        - MaterialRadioButton.cs
        - MaterialScrollBar.cs
        - MaterialSlider.cs
        - MaterialSnackBar.cs
        - MaterialSwitch.cs
        - MaterialTabSelector.cs
        - MaterialTextBox.cs
        - MaterialTextBox2.cs

    - moved several const declarations and enum declarations that were shared among files to a new file Globals.cs
        - MaterialDrawer.cs

  - Enhancement - compatibility with Msft CLI/C++:
    - enum value MouseState.OUT (IMaterialControl.cs) renamed to MouseState.OUT_
      - "OUT" keyword is a reserved word on CLI/C++.
-------------------------
  - Enhancements:
    - Added support for "UserControl" Containers
      - Previous versions only supported placing controls like MaterialDialog if the Parent Container was of a type that inherits from Winform (Form class), like MaterialForm or plain Winform. Adding MaterialDialog control to a custom UserControl would generate a runtime exception because MaterialDialog._formOverlay was expecting an "Onwer" of type "Form" which is not the case when using parent containers like UserControls.
      - Changed class "MaterialDialog" to expect a Parent-container of type "ContainerControl", Form and UserControl classes inherit from ContainControl class.
      - Affected files:
        - MaterialDialog.cs
        - MaterialSkinManager.cs

    - Improved design-mode experience of MaterialDrawer when combined with MaterialTabControl object. Now, during design-time, it's possible to view the drawer and the design impact on it when drawer's and tabcontrol's properties are changed by the user.

    - Improved performance of MaterialDrawer during initialization
      - Reduced the number of "Redraws" (Pain events) while the MaterialDrawer control is being initialized by its container.
        - Previously, during MaterialDrawer's initialization, every property set done by the container that would impact drawer's UI would generate a redraw event (paint event).
        - Now, MaterialDrawer control checks if its container has finish the initialization and if not ignores the redraw. When container invokes control's "InitLayout" method, meaning "end of control's initialization phase, future propertities changes will invoke a redraw action.
@orapps44
Copy link
Collaborator

Hi @nfasvp ,

Thank you for your work.

This PR seems somehow allready part of PR #338 , do you confirm ?

@nfasvp
Copy link
Author

nfasvp commented Feb 25, 2022

Hi @leocb , yes, this PR contains #338 changes.

@orapps44
Copy link
Collaborator

Duplicate of #338

@orapps44 orapps44 marked this as a duplicate of #338 Feb 25, 2022
@orapps44 orapps44 closed this Feb 25, 2022
@nfasvp
Copy link
Author

nfasvp commented Feb 28, 2022

Hi @orapps44, my bad, I wanted to say that PR #338 is part of #339, so #338 is the duplicate, not #339.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants