Quantcast
Channel: Extended WPF Toolkit™ Community Edition
Viewing all 4964 articles
Browse latest View live

New Post: Magnifier memory leak?

$
0
0
Hi all,

I've been using the magnifier control for an image viewing project where a user can open multi-page TIFF images, change page, rotate etc.

The magnifier works great but I seem to be having a problem where every time a new image or page is loaded to the viewer, the app memory increases (more so with bigger images) until eventually it throws an out of memory exception and crashes the app. I have tried without the magnifier control and it works fine so it is definitely this causing the issue.

I was wondering if there was a way to dispose or clear the memory for it, which I can call whenever the user changes the displayed image? Hiding the magnifier (visible) doesn't help and I couldn't see any other obvious way to achieve this.

Any help resolving this would be greatly appreciated.

Created Unassigned: DropDownButton : Position of Popup [22176]

$
0
0
A user wrote : "Is there a styling I can use to get the DropDownContent to appear to the right of the button rather than below?"

New Comment on "DropDownButton"

$
0
0
Issue https://wpftoolkit.codeplex.com/workitem/22176 has been created.

Edited Feature: DropDownButton : Position of Popup [22176]

$
0
0
A user wrote : "Is there a styling I can use to get the DropDownContent to appear to the right of the button rather than below?"
Comments: ** Comment from web user: BoucherS **

Currently, you have to modify the default DropDownButton style to position the popup to the right of the cotnrol. You can find the file to modify here :
-Xceed.Wpf.Toolkit/DropDownButton/Themes/Aero2.NormalColor.xaml (in Windows 8)
-Xceed.Wpf.Toolkit/DropDownButton/Themes/Generic.xaml (in other Windows)
Look for the "Popup" and replace the "Placement="Bottom"" for "Placement="Right"".

In v3.0, a new property will be available on the "DropDownButton" and "SplitButton" to position the popup anywhere relative to the control.

New Post: Update item names in CollectionControlDialog from PropertyGrid

$
0
0
Hi,

Toolkit v3.0 will have a fix for this issue.

Created Unassigned: RangeSlider : Set LowerValue greater than HigherValue [22179]

$
0
0
A user wrote : "There seems to be a problem when binding to controls that don't have the same limiting factors as the range sliders. Setting the lower value higher than the higher value moves both thumbs up but does not update the higher value binding. Setting the higher value lower than the lower value does not move either thumb, and also does not update the binding. Is there a way around this other than forcing a binding update every time?"

New Comment on "RangeSlider"

$
0
0
Hi, Issue https://wpftoolkit.codeplex.com/workitem/22179 has been created.

Edited Issue: RangeSlider : Set LowerValue greater than HigherValue [22179]

$
0
0
A user wrote : "There seems to be a problem when binding to controls that don't have the same limiting factors as the range sliders. Setting the lower value higher than the higher value moves both thumbs up but does not update the higher value binding. Setting the higher value lower than the lower value does not move either thumb, and also does not update the binding. Is there a way around this other than forcing a binding update every time?"
Comments: ** Comment from web user: BoucherS **

This issue will be fixed in v3.0.
In that version,
-setting a LowerValue greater than HigherValue will be impossible. LowerValue and HigherValue will be set to HigherValue.
-setting a HigherValue smaller than LowerValue will be impossible. LowerValue and HigherValue will be set to LowerValue.
Bindings will be correctly updated for both cases.


New Post: Update item names in CollectionControlDialog from PropertyGrid

New Post: Magnifier memory leak?

$
0
0
Hi,

This is interesting.
Can you submit a small sample so we could see how you create and use the Magnifier ?
Thanks.

Created Unassigned: Extended WPF Toolkit not supported in Universal App [22180]

$
0
0
In Visual Studio 2015, creating a new Blank App (Universal Windows) targeting .NET Framework 4.5.2 and attempting to add Extended WPF Toolkit Community Edition 2.6.0 via NuGet results in the following error and the package reference not being added to the project:

Restoring packages for C:\<PathToProject>\project.json...
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0.
Some packages are not compatible with UAP,Version=v10.0.
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-arm).
Some packages are not compatible with UAP,Version=v10.0 (win10-arm).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-arm-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-arm-aot).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x86).
Some packages are not compatible with UAP,Version=v10.0 (win10-x86).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x86-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-x86-aot).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x64).
Some packages are not compatible with UAP,Version=v10.0 (win10-x64).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x64-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-x64-aot).
Package restore failed for '<ProjectName>'.

Commented Unassigned: Extended WPF Toolkit not supported in Universal App [22180]

$
0
0
In Visual Studio 2015, creating a new Blank App (Universal Windows) targeting .NET Framework 4.5.2 and attempting to add Extended WPF Toolkit Community Edition 2.6.0 via NuGet results in the following error and the package reference not being added to the project:

Restoring packages for C:\<PathToProject>\project.json...
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0.
Some packages are not compatible with UAP,Version=v10.0.
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-arm).
Some packages are not compatible with UAP,Version=v10.0 (win10-arm).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-arm-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-arm-aot).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x86).
Some packages are not compatible with UAP,Version=v10.0 (win10-x86).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x86-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-x86-aot).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x64).
Some packages are not compatible with UAP,Version=v10.0 (win10-x64).
Extended.Wpf.Toolkit 2.6.0 is not compatible with UAP,Version=v10.0 (win10-x64-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-x64-aot).
Package restore failed for '<ProjectName>'.
Comments: ** Comment from web user: BoucherS **

Hi,

No, the Toolkit is not supported with Universal App.

New Comment on "PropertyGrid"

$
0
0
Are the examples correct? When I try the example code from the section "Custom Editors with DataTemplates", I get an error on the line <xctk:EditorTemplateDefinition TargetProperties="{x:Type sys:Double}"> which says "The specified value cannot be assigned. The following type was expected: 'IList'."

New Comment on "PropertyGrid"

$
0
0
Hi, This is not an error. TargetProperties is an IList, but you can set it in XAML with a type, or strings separated by comma. An internal TypeConverter is used to convert what you pass and add it to a List. The error is only present in the Designer. To prevent the error, you can rewrite the lines : <xctk:EditorTemplateDefinition TargetProperties="{x:Type sys:Double}"> ... </xctk:EditorTemplateDefinition> by <xctk:EditorTemplateDefinition> <xctk:EditorTemplateDefinition.TargetProperties> <xctk:TargetPropertyType Type="{x:Type sys:Double}" /> </xctk:EditorTemplateDefinition.TargetProperties> ... </xctk:EditorTemplateDefinition>

New Post: AvalonDock - overlaying a floating window; zIndex issue

$
0
0
Hi,

The LayoutFloatingWindowControl is a Window. Its content is a FloatingWindowContentHost, which is a HwndHost.
Based on this MSDN Technology Regions Overview (https://msdn.microsoft.com/en-us/library/aa970688(v=vs.100).aspx), there could be problems rendering WPF on top of Win32.

To prevent Maximize/Minimize... on floating Window, you can modify the Style in Generic.xaml file as you started to do.
Declare your "OVERLAY_GRID" after the "WindowBorder" so it will appear over it. It will hide to Window title's buttons.

To Disable the content of the LayoutFloatingWindowControl,
go in file Xceed.Wpf.AvalonDock/Controls/LayoutFloatingwindowControl.cs,
in class FloatingWindowContentHost,
in method BuildWindowCore
and add :
_rootPresenter.IsEnabled = false;
right after _rootPresenter has been instanciated.

To prevent movement of LayoutFloatingWindowControl,
go in file Xceed.Wpf.AvalonDock/Controls/LayoutFloatingwindowControl.cs,
in method FilterMessage
in case Win32Helper.WM_SYSCOMMAND:
and add :
else if( command == Win32Helper.SC_MOVE )
                    {
                      bool canMove = true;  //change to false to prevent movement
                      if( !canMove )
                      {
                        handled = true;
                      }
                    }
where SC_MOVE should be declared in Xceed.Wpf.AvalonDock/Win32Helper.cs as
internal const int SC_MOVE = 0xF010;

New Comment on "PropertyGrid"

$
0
0
BoucherS, Thank you for the quick reply. I can confirm that your change eliminates the error from the Designer. However, I'm also getting a runtime error, and that persists even with the change. The error is: Object of type 'System.RuntimeType' cannot be converted to type 'System.Collections.IList'. From your comment, it sounds like you are not getting the runtime error. I wonder what we are doing differently. I've tried to replicate the example in as much detail as possible. I'm using Visual Studio 2015 running .NET 4.5.2. I can't ask you to help me troubleshoot this, but if you have any ideas, please let me know.

New Post: AvalonDock - overlaying a floating window; zIndex issue

$
0
0
Hi Boucher,

thanks for looking into this!

Unfortunately, these modifications didn't quite work out for me - e.g. while the SC_MOVE event was called, setting it to handled = true didn't have any effect on moving the window.

Is it correct that the FloatingWindowContentHost is not the entire floating window as such, but just the content area within the floating window - i.e., everything that ISN'T red in this image?

Image

If so, what is the reason behind using a HwndHost here; is this just to be able to host WinForm controls or something like Win32 Windows inside avalondock? Would there be a need to use HwndHost if my project only ever used plain WPF controls?

I've just tried replacing the FloatingWindowContentHost by a simple Contentpresenter by changing the function
    public abstract class LayoutFloatingWindowControl : Window, ILayoutControl
    {
        // ... other functions etc ...

        static object CoerceContentValue(DependencyObject sender, object content)
        {
            return new ContentPresenter() { Content = content };
            //don't use this anymore: return new FloatingWindowContentHost(sender as LayoutFloatingWindowControl) { Content = content as UIElement };
        }
    }
At first glance, this works fine. My OVERLAY_GRID correctly hides the entire window now, all other functions seem to be working as usual too.
Can you think of any side effects though, or does this seem like an ok solution if I plan to only host WPF (no WinForms) controls?

Thanks!

New Comment on "PropertyGrid"

$
0
0
Hi T_C, I don't have a runTime error. Can you create an issue and add a sample project producing the bug ? Thanks.

New Post: AvalonDock - overlaying a floating window; zIndex issue

$
0
0
Hi BogeyLab,

Hum, this is strange that setting handled = true into SC_MOVE didn't prevent the floating window from being moved around. I can move the floating Window, but as soon as I drop it, I can't move it anymore because I set handled = true into SC_MOVE.

For the rest, yes, this was a project requirement to support WinForms control, so HwndHost was used in floating Windows. If you are using plain WPF, you can just remove the "CoerceContentValue" callback. Floating Window default ContentPresenter will take care of setting its content properly. I didn't fully test this modification, but I would say you can use it this way. I don't see any side effects until now.

New Post: AvalonDock - overlaying a floating window; zIndex issue

$
0
0
Just make sure to add :
 if( host != null )
                {
                  host.Dispose();
                }
in LayoutFloatingWindowControl.OnClosed() method, right after :
var host = Content as FloatingWindowContentHost;
to prevent any crash;
Viewing all 4964 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>