Diwore

origin: http://blogs.msdn.com/b/jgoldb/archive/2010/06/14/memory-leak-hotfixes-for-wpf-3-5-sp1.aspx

Hopefully folks saw my related blog post Finding Memory Leaks in WPF-based applications .
In this post below I wanted folks to be aware that we released few other KB Articles (Hotfix) that address other various memory leaks reported in .NET 3.5 SP1. Some of these fixes made it to .NET 4.

1. KB981107 (See: http://support.microsoft.com/kb/981107)

This Hotfix fixes the following memory leaks in .NET 3.5 SP1 WPF-based applications.
Issue 1:
This affects an app that contains styles or templates that refer to application resources (via StaticResource or DynamicResource), and that creates a large number of elements that use these styles or templates but never need the actual value of the resource.  In this situation, the app can leak DeferredAppResourceReference objects, even after the elements themselves have been reclaimed.  (In addition, the app can leak WeakReferences and array space, similar to the issues described below.)

An example:  App resources define   <sys:Double x:Key="{x:Static SystemParameters.HorizontalScrollBarHeightKey}">20</sys:Double>     This creates a resource that's used by any control that can display a horizontal scrollbar.  Creating a large number of such controls that never actually display their scrollbar will encounter the leak.

Issue 2:
This affects an app that creates a large number of short-lived elements with properties that are data-bound to a DependencyProperty of longer-lived elements. In this situation, the longer-lived elements maintain lists of WeakReference objects, used to notify the short-lived elements about property changes. The app can leak WeakReference objects and the array space to hold them, even after the short-lived elements have been reclaimed.

An example:   ListBoxItem binds its HorizontalContentAlignment property to a similar property on its governing ListBox.   An app that creates a large number of ListBoxItems (say by doing a large number of additions and deletions to the ListBox's ItemsSource) will encounter the leak.

Issue 3:
This issue affects classes derived from TreeView or Selector (including ListBox, ListView, Menu, DataGrid, and many others).   These classes register for an internal notification from the KeyboardNavigation class, used for controlling keyboard focus.   An app that creates a large number of these elements can leak WeakReference objects and the array space to hold them, even after the elements themselves have been reclaimed.
An example:  An app that creates a large number of short-lived ListBoxes will encounter the leak.  This can happen in a nested scenario, where an outer ListBox displays a collection that undergoes a large number of additions and deletions, and where each item is displayed using an inner ListBox.

These fixes are not included in NET4. We are considering this Hotfix also for NET4, but this decision has not been made, so stay tune.

2. KB967634: (See: http://support.microsoft.com/kb/967634 )

This fixes a memory leaks in .NET 3.5 SP1 WPF-based applications when using software 3D rendering involving a VisualBrush or DrawingBrush.
This fix is already included in .NET 4.

3. KB967328 (See: http://support.microsoft.com/Default.aspx?kbid=967328)

This Hotfix fixes memory leaks when a deferred resource isn't inflated due to the resource reference expression hooking up to the Inflated event on the resource dictionary entry.
If the resource dictionary is an application or theme dictionary, then these are essentially global and can cause these expressions to stay alive.
There are some discussions on this issue here.
This fix is already included in .NET 4.

Origin Web: http://www.rainsts.net/article.asp?id=474

In the last post, I wrote about how focus is generally managed in WPF - we have focus scopes to track a single element within that scope for logical focus, and then one of those elements is given physical, or keyboard focus.

Now, let's talk a little about how you can influence that programatically. First, you can always determine which element has logical focus in your application through the FocusManager.GetFocusedElement method -- pass it the window in question and it will return which element has logical focus in that window. Remember that logical focus != keyboard focus at all times -- toolbars and menus track their own focus so if you are currently interacting with a menu then the menu has physical focus. But in general, the following code will tell you which element WPF thinks has focus in the window:

IInputElement focusedElement = FocusManager.GetFocusedElement(thisWindow);

1. The element has Focusable = false
2. The element has Enabled = false
3. The element has IsVisible = false
4. The element has not been loaded yet
5. The currently focused element will not release focus.

1. Continue - each focusable element receives focus and the container is exited when the edge is reached.
2. Cycle - focus does not leave the container but wraps around the edges
3. Once - the container itself is treated as a single focusable element where only the first child receives focus
4. Local - uses TabIndex locally within the container - independant of any outside elements.
5. Contained - focus statys in the container but does not wrap (stays at edges when top/bottom are reached)
6. None - no keyboard navigation allowed in the container

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Title="Simple Focus">

<Window.Resources>
<Style TargetType="TextBox">
<Setter Property="Margin" Value="10" />
<Setter Property="Width" Value="100" />
</Style>
</Window.Resources>

<StackPanel>
<ComboBox x:Name="tabStyles" SelectedIndex="0" Focusable="False">
<sys:String>None</sys:String>
<sys:String>Continue</sys:String>
<sys:String>Cycle</sys:String>
<sys:String>Once</sys:String>
<sys:String>Local</sys:String>
<sys:String>Contained</sys:String>
</ComboBox>

<TextBox TabIndex="1" />
<TextBox TabIndex="2" />
<StackPanel
KeyboardNavigation.TabNavigation="{Binding ElementName=tabStyles,Path=SelectedItem}">
<TextBox TabIndex="1" />
<TextBox TabIndex="2" />
</StackPanel>
</StackPanel>
</Window>

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Title="Simple Focus"
FocusManager.FocusedElement="{Binding ElementName=tb2}">
...
<TextBox TabIndex="1" />
<TextBox x:Name="tb2" TabIndex="2" />
...
</Window>

Origin : http://www.julmar.com/blog/mark/PermaLink,guid,6e4769e5-a0b3-47b2-a142-6dfefd0c028e.aspx

命令格式：Subst [Drive1:] [Drive2:＼Path]
作用：映射某磁盘中的文件到另一个磁盘。eg. Subst e: "C:\My Disk(E)"

删除操作：
Subst e: /D

顺便提一下可以用这个方法隐藏软盘A，方法如下：
在运行中输入：sysedit
在C:＼AUTOEXEC.BAT文件中输入相应的命令，表示重启就运行批处理文件。

贴个C++的运算符优先级表，给大家和自己有个参考吧！

http://www.cppreference.com/wiki/operator_precedence

Code
#include <iostream>

public A
{
public:
    void f()
    {
        std::cout << "A::f()" << std::endl;
    }
};

public B : public A
{
public:
    void f()
    {
        std::cout << "B::f()" << std::endl;
    }
};

public C : public A
{
public:
    void f()
    {
        std::cout << "C::f()" << std::endl;
    }
};

public D : virtual public B, public C
{
};

然后D的对象直接调用f()也会出错，会有二义性，解决方法是加上类的修饰符。
如

D d;
d.B::f();
d.A::f();

最近我们在工作中碰到一个奇怪的问题，最后确定是多继承引起的指针漂移，跟C++对象模型有关。示意如下：

class A {...};
class B{...};
class AB : public B, public A {...}
...
AB *pab = new AB();
A* pa = (A*)pab;
B* pb = (B*)pab;

这时候你发现pa和pb的值是不一样的！它们中有一个跟pab是相等的，而另外一个产生了偏移。如果把AB的声明中A和B的顺序调换一下，则产生偏移的指针也会变为另外一个。

为了确定这是编译器做了转换的缘故，利用void指针愚弄编译器：
void *pv = (void*)pab;
pa = (A*)pv;

这时候pa的值倒是跟pab相等了，然而指向了错误的地方。从pab到pa的转换，依赖于路径的选择，让人不是很放心。还不知道把指针放入容器中再取出来，会不会出错。当然，上面使用了强制类型转换，在良好的程序中应该避免。如果只有隐式转换，可以得到正确的结果：

 std::vector<A*> v;
 //implicit type conversion
 v.insert(v.begin(), pab);
 void *pv = v[0];
 pa = (A*)pv;

以下程序使用Cygwin/g++b编译通过：

#include <stdio.h>
#include <vector>

class A
{
public:
 int a;
};
class B
{
public:
 int b;
};
class AB : public B, public A
{
public:
 int ab;
};

int main(int argc, char **argv)
{
 AB *pab = new AB();
 pab->ab = 1;
 pab->b = 2;
 pab->a = 3;

 A* pa = (A*)pab;
 B* pb = (B*)pab;

 printf( "AB: %p\n" \
  " A: %p\n" \
  " B: %p\n",
  pab, pa, pb);

 std::vector<A*> v;
 //implicit type conversion
 v.insert(v.begin(), pab);
 void *pv = v[0];
 pa = (A*)pv;
 printf("pv is %p\npa is %p\npab %s pv\n", pv, pa, (pab == pv) ? "==" : "!=");

 printf("A.a is %d\n", pa->a);
 //forced type conversion
 pv = (void*)pab;
 pa = (A*)pv;
 printf("Now A.a is %d\n", pa->a);
}

运行结果：
AB: 0x6b01f0
A: 0x6b01f4
B: 0x6b01f0
pv is 0x6b01f4
pa is 0x6b01f4
pab != pv
A.a is 3
Now A.a is 2