这变成了一个相当长的帖子,并且每个说法并没有真正的"答案".我更倾向于寻找解释,而不是解决问题.因此,您要回答的任何方面都会非常感激.提前致谢!
我正在遇到文件系统对象可能存在的"问题",这导致了一个关于VBA中的文件系统对象如何工作的功能等问题与"别的东西"(我不知道)如果有替代方法可以在Excel中使用我正在做的事情.net等我不知道有什么更好的地方可以问,而且我不确定该为自己研究什么.所以我来了!
所以!为了这个问题.简短的解释是我遍历文件夹,收集文件信息(名称,扩展名,完整路径等)并将其放入电子表格中.我最终使用此信息将文件复制到新位置.但是,在大规模(1,000多个文件)中,这似乎在本地工作得很好,但在网络位置(工作中)它相当慢.它将咀嚼1,500个文件,等待一段时间,再做1,500多个等等.列出或复制文件时.同样,在本地完成时不会出现这种情况,它只会毫无问题地运行,所以我可以假设它可能与我的代码无关.这几乎就像网络间歇性地打开和关闭一个门.
或者,从最终用户的角度使用其他程序(我尝试使用我的程序,在我们的工作网络上使用的相同文件),没有任何上述延迟,它会更快.我假设替代程序正在使用某些版本的.net,如果重要的话.长话短说,我不认为我本来可以责怪我们的网络因为我遇到的速度问题.
所以我的问题/好奇心/问题归结为几个关键点:
- VBA中的FSO与.Net中的默认库之间有什么区别？我遇到的问题原因之间的区别是什么？显然,可以比完成这些数据更快地读取此类数据.
- FSO不打算以这种方式使用(通过网络,使用大量远程数据,还是......？)？它只是过时/过时了吗？有没有可以通过VBA使用的替代方案？
- 我只是模糊地了解我们的网络以与本地驱动器不同的方式运行.它存储了数TB的数据等,我不确定访问本地驱动器和网络位置之间的差异是什么.我知道我没有提供可能对诊断非常有益的网络细节,遗憾的是我不知道这些信息.我想我只是问它是否"潜在地"解释了以这种方式使用FSO与某些/所有类型的网络并不是它的意思.是否有可能以这种方式设置网络以限制我尝试与之交互的方式？
- 即使我在本地没有遇到任何问题,我的代码中的某些东西是否可能对网络位置和本地驱动器更加负担？
感谢您提供的任何见解.
全新的WPF,非常适合WinForms(这可能使转换变得更加粗糙).我正在尝试将旧的WinForms项目中的一些功能移植到WPF作为学习体验.
目标是在DataGrid中查找与TextBox中的字符串匹配的单元格值.我发现了一个使用绑定的好例子.基本上链接的代码会将任何匹配的DataGridCell的背景颜色更改为橙色.我已经修改了我的版本,但功能应该是相同的.请参阅代码示例的链接,这里提供它似乎有点多余.填充我的DataGrid的数据来自DataTable(如果重要的话).
我想要做的是有一个"下一步"按钮,它将遍历每个单元格(通过使用背景颜色或自定义属性DataGridTextSearch.IsTextMatch确定)并选择它.似乎可以只修改一些提供的代码,但我不知道从哪里开始.在我的旧WinForms项目中,我将DataGridViewCell存储在一个列表中(在使用Linq查询找到它们之后)并且只是附加了按钮行为以递增所述列表并设置当前单元格.我怀疑可能有更聪明/更好的方式涉及绑定,我甚至不知道如何将这些匹配的单元格添加到列表中,如果这是一个选项.
因此,总而言之,我想要一个循环遍历特定DataGridCells的按钮(基于Background或自定义DataGridTextSearch.IsTextMatch属性)并选择它们.
提前致谢.