为什么在嵌套深度时Windows窗体对接无法正常工作? [英] Why does Windows Forms docking not work properly when nesting is deep?

查看:71
本文介绍了为什么在嵌套深度时Windows窗体对接无法正常工作?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好。我希望有一个人可以帮助我。几个星期以来,我一直在摸不着头脑,似乎无处可去。



问题是这个。当您将控件嵌套在其他控件和用户控件中时 - 例如,深度为六级或七级 - 内部控件(在此特定情况下为多行文本框)在父控件更改大小时不会正确调整大小。



哦,它不仅无法改变大小。那很简单。不,它的界限会发生变化,并且在一些(但不是全部)情况下它会正确地重新绘制,但是文本继续包裹在同一个地方,即使控件大小已经改变。



我在编写自定义面板控件时首次遇到此问题,并认为这只是我代码中的一个错误。昨天我把头撞到墙上一段时间后无处可去,昨天我决定拿一份我的代码并删除一下,直到问题消失为止。



< b>我删除了所有代码。 问题仍然存在。



剩下的唯一代码是Visual Studio的GUI代码当您向设计表面添加控件时,会在幕后添加,并为各种控件添加少量额外代码,以便我可以看到正在发生的事情。



现在,我不能很好地粘贴Windows窗体设计器代码 - 这是非常冗长的,因为这样的代码往往是。另外,还有六个不同的类(几乎都是空的)。所以我做的是,我已经将源和可执行文件分别上传到MegaUpload:



来源:http://www.megaupload.com/?d=LDP09KRY [ ^ ]

可执行文件: http: //www.megaupload.com/?d=P7QKDMJJ [ ^ ]



如果您不信任可执行文件,只需下载源代码即可。它包含一个VS2010项目和解决方案,以及六个不包含代码的用户控件。



要重现问题,请运行编程并观察三组同心正方形。每个都是面板,tablelayoutpanel或usercontrol。每个中心都是一个文本框。使窗口更宽,并注意顶部文本框中​​的文本不会重新换行以适应文本框的新宽度。



如果文本框本身看起来没有调整大小,则它只是无法重新绘制自身。单击其他文本框之一,然后单击有问题的文本框,它将重新绘制。请注意,文本仍然会被错误地包裹。



有趣的是,如果我只是嵌套控件而不是使用(无代码)自定义控件;或者如果我使用单行文本框,或者说是一个按钮;问题消失了。据我所知,问题实际上并不是限制多行文本框,但在这种情况下我只能用它们重现它。



我非常感谢这些家伙的一些帮助。我尝试的任何东西似乎都没有帮助。我已经尝试添加对PerformLayout等的调用,但他们什么也没做。 (令人担忧的是,布局代码的Microsoft源代码包含的注释不应该需要这一点,但是如果我把它拿出来,事情就会破坏。我认为微软应该理解这个东西?)



请不要建议愚蠢的事情,比如不要使用对接或不要嵌套控件如此深刻 - 他们没有帮助。原因是,对接是在.NET中安排控件的官方方法;即使我觉得能够降低筑巢水平(无论如何我都不应该这样做),我无法控制其他人选择嵌入我的控制的深度。嵌套应该有效。停靠应该有效。

Hi. I hope someone can help me. I've been scratching my head on this one for weeks, and can't seem to get anywhere.

The problem is this. When you nest controls inside other controls and usercontrols - say, six or seven levels deep - the inner control (which in this particular case is a multiline textbox) doesn't resize properly when the parent controls change size.

Oh, it doesn't just fail to change size. That would be simple. No, its bounds change, and in some (but not all) cases it repaints itself properly, but the text continues to wrap at the same place, even though the control size has changed.

I first encountered this problem when I was writing a custom panel control, and thought it was just a bug in my code. After banging my head against a wall for a while and getting nowhere, yesterday I decided to take a copy of my code and remove bits until the problem went away.

I removed all the code. The problem remained.

The only code remaining is the GUI code that Visual Studio puts in behind the scenes when you add controls to the design surface, and a tiny amount of extra code to colour the various controls so I can see what is going on.

Now, I can't very well paste the Windows Forms Designer code in here - it's quite long-winded, as such code tends to be. Plus, there are half a dozen different classes (all pretty much empty). So what I've done is, I've uploaded the source and the executable separately to MegaUpload:

Source: http://www.megaupload.com/?d=LDP09KRY[^]
Executable: http://www.megaupload.com/?d=P7QKDMJJ[^]

If you don't trust executables, just download the source. It consists of a VS2010 project and solution, along with half a dozen usercontrols that contain no code.

To reproduce the problem, run the program and observe the three sets of concentric squares. Each is a panel, tablelayoutpanel, or usercontrol. In the centre of each is a textbox. Make the window wider, and notice that the text in the top textbox does not re-wrap to fit the new width of the textbox.

If the textbox itself appears not to resize, it has merely failed to repaint itself. Click on one of the other textboxes, then click on the offending textbox, and it will repaint. Notice that the text will still be wrapped incorrectly.

It is interesting to note that if I simply nest controls instead of using (codeless) custom controls; or if I use a single-line textbox or, say, a button; the problem goes away. As far as I recall, the problem isn't actually limited to multiline textboxes, but I've only been able to reproduce it with them in this case.

I'd really appreciate some help here guys. Nothing I try seems to help. I've tried adding calls to PerformLayout and such, and they don't do anything. (Worryingly, the Microsoft source for the layout code contains comments along the lines of "this bit shouldn't be needed, but if I take it out, things break". I thought Microsoft were supposed to understand this stuff?)

Please don't suggest silly things like "don't use docking" or "don't nest your controls so deep" - they aren't helpful. Reason being, docking is the official method of arranging controls in .NET; and even if I felt able to reduce the nesting level (which I shouldn't have to do anyway), I have no control over how deep anyone else chooses to nest my control. Nesting should work. Docking should work.

推荐答案

这听起来像我刚刚解决的问题。内核堆栈太小了。它是Windows的一个限制。它在x64 Windows中比x86更快,因为地址是两倍大小,但内核堆栈保持不变。



更多信息(以及解决方法):



http://support.microsoft.com/kb/953934
This sounds like a problem I have just fixed. The kernel stack is too small. Its a limitation of Windows. It happens faster in x64 Windows than x86, since the address is twice the size, but the kernel stack remained the same.

For more info (and a workaround):

http://support.microsoft.com/kb/953934


抱歉,我现在无法加载您的项目。我可以给你一些想法。



我的方法不同。使用Designer变得危险时,存在一定的复杂性限制。这个限制非常低。对于更复杂的布局,大多数工作应该在代码中完成。 Designer始终是手动工作,无需重复使用。如果你看一下自动生成的代码,它就不像你自己做的那样可读。



例如,如何解决这个问题:制作统一到处都是填充物,填充物的厚度在一个地方定义?仅限代码。设计师违反了不要重复自己(DRY)原则( http://en.wikipedia。 org / wiki / Don%27t_repeat_yourself [ ^ ]);因此,它无法在复杂和正确的UI中合法使用。有了设计师,你无法真正看到布局。控件互相覆盖;具有 DockStyle.None 的控件可以对齐为停靠并且看起来像停靠。基本上,你需要保持所有控件停靠。



顺便说一句,一个简单的想法有时会有所帮助:用不同的背景颜色为所有控件着色。你可能会看到你现在看不到的问题。



我经常使用一个简单的架构:使用Designer,我只添加状态栏,main菜单和中心的一个主面板,填充空间,而不是我在这个主面板中添加面板。其他一切都是用代码完成的。



-SA
Sorry I cannot load your project right now. I can give you some ideas.

My approach is different. There is a certain limit of complexity where using Designer becomes dangerous. This limit is pretty low. For more complex layouts, most of the works should be done in code. Designer is always manual work and no reuse. If you look at auto-generated code, it is not as readable as you can make on your own.

For example, how to solve this problem: "make uniform padding everywhere, and the thickess of padding is defined in one place"? Only in code. Designer violates the Don't Repeat Yourself (DRY) principle (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself[^]); so, it cannot be legitimately used in complex and correct UI. With designer, you cannot really see the layout. Controls cover each other; a control with DockStyle.None can be aligned as docked and looks like docked. Basically, you need to keep all controls docked.

By the way, a simple idea which can help sometimes: color all controls with different background colors. You might be able to see the problem which you don't see right now.

I often use one simple schema: with Designer, I only add status bar, main menu and one main panel in the center, filling the space, than I add the panels in this main panels. Everything else is done in code.

—SA


嗯,这是一个开源实现嵌套对接尝试下载此功能,如果这种类似的实现可以帮助您解决问题,请 http://sourceforge.net/projects/dockpanelsuite/ [ ^ ]
Well, here is an opensource implementation of nested docking. Try downloading this and Should this similar implementation help you figure out your issue, http://sourceforge.net/projects/dockpanelsuite/[^]


这篇关于为什么在嵌套深度时Windows窗体对接无法正常工作?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆