我在.NET 3.5中遇到过一个错误(我假设).使用Rows.Add()向DataGridView添加行时,如果禁用DGV,则垂直滚动条无法正确更新.因此,在重新启用DGV后,无法使用滚动条或鼠标滚轮一直滚动到DGV的底部(尽管使用箭头键导航仍然有效.)
所以我正在寻找一种解决方法.有没有办法强制滚动条更新其边界,还是可以手动输入新的最大值？我宁愿不必重新填充DGV.
*)实际上,它是被禁用的父表单,但我认为问题是它传播到DGV控件.
我正在用C#编写客户端/服务器应用程序,而且它很棒.现在,一切正常,而且非常强大.我的问题是,当通过连接发送数据包时,我遇到了一些延迟.
在客户端我这样做:
NetworkStream ns = tcpClient.GetStream();
// Send packet
byte[] sizePacket = BitConverter.GetBytes(request.Length);
byte[] requestWithHeader = new byte[sizePacket.Length + request.Length];
sizePacket.CopyTo(requestWithHeader, 0);
request.CopyTo(requestWithHeader, sizePacket.Length);
ns.Write(requestWithHeader, 0, requestWithHeader.Length);
// Receive response
ns.Read(sizePacket, 0, sizePacket.Length);
int responseLength = BitConverter.ToInt32(sizePacket, 0);
byte[] response = new byte[responseLength];
int bytesReceived = 0;
while (bytesReceived < responseLength)
{
int bytesRead = ns.Read(response, bytesReceived, responseLength - bytesReceived);
bytesReceived += bytesRead;
}
(遗漏了一些异常捕获等)服务器执行相反的操作,即它在NetworkStream.Read()上阻塞,直到它有一个完整的请求,然后处理它并使用Write()发送响应.
Write()/ Read()的原始速度不是问题(即发送大数据包很快),但是在不关闭连接的情况下一个接一个地发送几个小数据包可能非常慢(延迟50-100)女士).奇怪的是,这些延迟出现在LAN连接上,典型的ping时间<1 ms,但如果服务器在localhost上运行则不会发生,即使ping时间实际上是相同的(至少差异不应该是大约100毫秒).如果我在每个数据包上重新打开连接,导致大量握手,那对我来说是有意义的,但我不是.这就好像服务器进入等待状态会使它与客户端失去同步,然后在重新建立本质上是丢失的连接时发现它有点绊倒.
那么,我做错了吗？有没有办法保持TcpServer和TcpClient之间的连接同步,以便服务器随时准备接收数据？(反之亦然:有时处理来自客户端的请求需要几毫秒,然后客户端似乎没有准备好接收来自服务器的响应,直到它在Read()上阻塞之后有一些时刻被唤醒.)
阿尔,我被卡住了!
我正在编写一个Excel加载项,打开一个自定义任务窗格(它是一种数据分析工具类型的东西).为了提高工作效率,我希望用户能够将对象(例如文件或电子邮件附件)拖到该任务窗格的一部分上进行处理,而不必通过一个或多个文件对话框.
问题是Excel似乎完全覆盖了自定义任务窗格及其包含的控件的拖放属性,因此当我将文件拖放到任务窗格时,Excel只是尝试将其作为电子表格打开(如果它是受支持的文件类型),我的DragDrop事件永远不会触发.
有没有办法让Excel停止这样做,以便将drop事件发送到任务窗格？
我正在尝试在已经从资源管理器窗口复制的VBA宏中加载文件.
我可以使用DataObject :: GetFromClipboard轻松地从剪贴板获取数据,但是DataObject的VBA接口似乎没有处理除纯文本之外的任何其他格式的方法.只有GetText和SetText方法.
如果我无法直接从DataObject获取文件流,文件名也会这样做,那么可能会强制GetText返回放在剪贴板上的文件的名称？
在任何地方都可以找到很少的VBA文档.:(
也许有人可以指出我有一个具有这种功能的VBA的API包装类？
我在 Word VSTO 加载项项目中有这样一行代码，它曾经可以工作，但突然不再工作了：
Microsoft.Office.Interop.Word.Document doc = Globals.ThisAddIn.Application.ActiveDocument;
在它按预期返回Document对象之前，我可以毫无问题地读取和操作它。但现在它抛出System.Runtime.InteropServices.COMException异常。“Word遇到了问题。” 很有帮助。该异常包含 0x800A13E9 的 HRESULT，到目前为止这也没有帮助我。内存不足还是怎么的？我不知道。
新行为似乎是在除夕夜左右开始的（不确定，因为过去几周我没有使用该加载项），并且它是在安装加载项时开始的，即代码中没有任何更改，重新编译或重新安装以使其发生。此后我重建了该项目，认为证书可能已过期或其他原因，但错误仍然发生。
也许值得注意的是，我仍然可以访问应用程序实例的其他属性。例如，这一行不会抛出异常：
int numDocuments = Globals.ThisAddIn.Application.Documents.Count;
但是当我使用 迭代集合时Documents，foreach它只是跳过循环，就好像计数为零一样。
我唯一能想到的是 Office (365) 的更新破坏了与 VSTO 相关的某些内容。但我从哪里开始调试呢？
好的，所以我尝试创建一个新的 Word VSTO 加载项，不更改任何默认项目属性，而是添加带有单个按钮的单个功能区和以下方法：
private void button1_Click(object sender, RibbonControlEventArgs e)
{
try
{
var x = Globals.ThisAddIn.Application.ActiveDocument;
}
catch (Exception ex)
{
;
}
}
它在获取 ActiveDocument 属性时抛出完全相同的异常。不过，我确实注意到，加载加载项时还会抛出两个异常，加载原始加载项时也会抛出这些异常（以前工作正常）：
Exception thrown: 'System.Deployment.Application.DeploymentException' in System.Deployment.dll
Exception thrown: 'System.Security.Cryptography.CryptographicException' in Microsoft.VisualStudio.Tools.Applications.Hosting.dll
它们不会阻止加载项加载和运行，但也许它们与问题有关？不知道去年问题出现之前是否也被抛出过。
不过，我确实有几个 Excel 加载项，它们仍然可以在相同版本的 VSTO、Visual …