问题列表 - 第3481页

我有一个小应用程序来转换几种文件格式,主窗口形式包含几个文本框,按钮等.我有另一个"文档"类,它处理所有的实际转换工作,我的表单基本上迭代所有的文件,并调用适当的Document方法来转换文件.然而,当这种情况发生时,表单会停止响应.我创建了另一个简单的表单,其中包含一个进度条和一个取消按钮,当转换开始向我们(容易被叮叮当当的)用户提供一些反馈时,它会产生.但是,当新表单加载时,所有控件都是白色框,并且它也停止响应.转换完成后,进度条将正常关闭,主窗体将再次响应.

是否有一种简单的方法可以使这两种形式独立,这样即使另一种形式没有反应,进度条也可以运行？

我总是感到惊讶的是,即使在现在使用C#之后,我仍然设法找到我不知道的事情......

我试过在网上搜索这个,但在搜索中使用"〜"对我来说效果不好,我在MSDN上也找不到任何东西(不是说它不存在)

我最近看到了这段代码,代字号(〜)是什么意思？

/// <summary>
/// Enumerates the ways a customer may purchase goods.
/// </summary>
[Flags]
public enum PurchaseMethod
{   
    All = ~0,
    None =  0,
    Cash =  1,
    Check =  2,
    CreditCard =  4
}

我看到它有点惊讶所以我试图编译它,它有效...但我仍然不知道它意味着什么/做了什么.任何帮助？

我已经为webform添加了标签控件.它出现在我运行页面但是当我尝试使用代码隐藏引用它时,我没有智能感知,我写的代码不能用.我已经验证了项目是在调试中运行的,调试编译是在web.config中设置的.事实上,我可以调试所有页面.但是,当我转到此页面时,调试会在其上运行,就像没有设置断点一样.此外,在断点处,它说'断点当前不会被击中.源代码与当前代码不同,后者是主要问题.当我重新编译整个项目时,不确定为什么会这样.

我在页面顶部有这个:

print("<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="MemberSearch.aspx.cs" Inherits="Portal.EmployerPortal.MemberSearch" Debug="true" %> ");

有任何想法吗？

在SQL Server中,您可以使用DATENAME函数将星期几作为字符串

declare @date datetime
set @date = '12/16/08'
select datename(dw, @date)

返回"星期二"

并且您可以使用DATEPART函数将星期几作为整数

declare @date datetime
set @date = '12/16/08'
select datepart(dw, @date)

返回3

但是说我有一个varchar,其中包含字符串"Tuesday",我想将其转换为3的整数表示.当然,我可以毫不费力地写出转换,但我宁愿使用内置函数.这样的功能存在吗？

注意 - 这个问题不是针对RoR或Redmine的插件系统

我一直在为Redmine开发一个自定义插件,Redmine是一个使用Ruby on Rails(RoR)构建的项目管理器平台.现在我不是一个真正的RoR或者那件事,一个Ruby家伙.我已经设法编写插件,一切正常,尽管幕后一团糟."你做错了!!" 感觉来自于我知道RoR是一个备受推崇的框架,所以必须有简单,更好,更优雅,[在这里插入最佳实践术语],做我做过的事情.我并不太关心使这段代码尽可能完美,唯一的原因是它只在内部使用,实际上,人们只关心它"有效"(我是唯一一个会看代码的人).

什么样的智慧可以传递来压制"你做错了!!" 感觉？我很确定如果这种感觉存在,那么手头的任务可能是错误的.

我有一个C#公共API,许多第三方开发人员都使用它来编写自定义应用程序.此外,API被内部开发人员广泛使用.

这个API并没有考虑到可测试性:大多数类方法都不是虚拟的,并且事物没有被分解到接口中.另外,还有一些辅助静态方法.

出于多种原因,我无法在不对使用我的API的程序员开发的应用程序进行重大更改的情况下显着更改设计.但是,我仍然希望使用此API的内部和外部开发人员有机会编写单元测试并能够模拟API中的对象.

有几种方法可以想到,但它们似乎都不是很好:

1. 传统方法是强制开发人员创建一个他们控制的代理类,以便与我的API通信.这在实践中不起作用,因为现在有数百个类,其中许多是有效的强类型数据传输对象,这将很难再现和维护.

2. 强制所有使用想要对其进行单元测试的API的开发人员购买TypeMock.这似乎很苛刻,迫使人们为每个开发人员支付300美元+,并可能要求他们学习不同于他们习惯的模拟对象工具.

3. 浏览整个项目并将所有方法设为虚拟.这将允许使用像Moq或Rhino Mocks这样的免费工具来模拟对象,但它可能会为从未打算从中派生的类带来安全风险.此外,这可能会导致重大变化.

4. 我可以创建一个工具,给定一个输入程序集将输出一个具有相同名称空间,类和成员的程序集,但会使所有方法都是虚拟的,它会使方法体只返回返回类型的默认值.然后,每次我发布API更新时,我都可以发送这个虚拟测试程序集.然后,开发人员可以针对虚拟程序集编写API测试,因为它具有非常可模拟的虚拟成员.这可能有用,但为此编写一个自定义工具似乎有点乏味,我似乎无法找到一个做得好的现有工具(尤其适用于泛型).此外,它的复杂性在于它要求开发人员使用可能会过时的两个不同的程序集.

5. 与#4类似,我可以遍历每个文件并为每个方法和正文添加类似"#ifdef UNITTEST"的内容,以完成与工具相同的操作.这不需要外部工具,但它会用很多丑陋的"#ifdef"来污染代码库.

还有其他我认为不合适的东西吗？像#4中提到的工具是否已经存在？

同样,复杂的因素是这是一个相当大的API(数百个类和~10个文件)并且使用它的现有应用程序使得很难进行剧烈的设计更改.

目前已经 过 几个 问题上堆栈溢出认为是通用性有关改造现有的应用程序,使之可测试的,但似乎没有解决我的(特别是在与众多第三方开发者广泛使用的API的情况下)的关注.我也知道" 有效地使用遗留代码 "并认为它有很好的建议,但我正在寻找一种特定的.net方法,考虑到上面提到的限制.

更新:到目前为止我很欣赏答案.一说帕特里克Hägne长大的是"为什么不能提取接口？" 这确实起到了一定作用,但是存在一些问题,例如现有的设计有很多我们采用暴露具体类的情况.例如:

public class UserRepository 
{ 
    public UserData GetData(string userName) 
    {
        ...
    } 
}

如果给予"IUserData",那么期望具体类(例如"UserData")的现有客户将会中断.

此外,正如评论中所提到的,我们会在某个类中接受一个类,然后为了方便而公开它.如果我们接受一个接口然后不得不将它作为具体类公开,这可能会导致问题.

重大改写或重新设计的最大挑战是对当前的API进行了大量投资(数千小时的开发,可能还有第三方培训).因此,虽然我同意一个更好的SOLID设计重写或抽象层(最终可能成为新的API),专注于接口分离原则等项目,从可测试性的角度来看会是一个加分,但它可能是一个很大的事业,可能目前不能成本合理.

我们确实测试了当前的API,但它是更复杂的集成测试而不是单元测试.

另外,正如Chad Myers所提到的,这个问题解决了.NET框架本身在某些领域面临的类似问题.

我意识到我可能正在寻找一个不存在的"银弹",但所有的帮助都值得赞赏.重要的是保护许多第三方开发人员的巨大时间投资以及创建当前API的巨大现有开发.

所有答案,尤其是那些考虑问题的业务方面的答案,都将得到认真审查.谢谢!

有没有人知道在Microsoft Word文档中显示代码以保留着色和格式的方法？优选地,该方法也是不显眼的并且易于更新.

我试图将代码包含为常规文本,看起来很糟糕,并且在编辑常规文本时会受到阻碍.我还尝试将对象,写字板文档和文本框插入到文档中,然后将代码放入这些对象中.代码看起来更好,在编辑其余文本时更容易避免.但是,这些对象只能跨越一页,这使得编辑成为需要添加几页代码的噩梦.

最后,我知道有更好的编辑器/格式处理这个问题没有问题,但我仍然坚持使用MS字.

在Java Web应用程序中,我有一个类型为A的重复消息加载(例如,每小时20,000个).然后我有第二种类型的消息(类型B)偶尔显示但具有比类型A更高的优先级(例如,3,000).我希望能够使用开源软件在一台或多台机器上处理这些消息.

在我看来,如果我有一个基于优先级从其队列发送消息的JMS服务器,我可以用JMS做到这一点(例如,发送三个类型B的消息,然后发送一个类型A的消息,即使类型A的所有消息都是在消息队列的顶部).

您是否知道可以执行此操作的JMS服务器 - 或者您是否知道另一种实现方法？

当只有一个可见标签时,隐藏标题页眉的最佳方法是什么？

我想完全隐藏TabControl chrome,同时保持Tab的内容可见.

我正在尝试在将新行插入表格时向多个收件人发送电子邮件.收件人列表各不相同.我希望能够使用select语句设置此列表.我也安装了Navicat,它允许我发送电子邮件通知,但仅限于预定的一组人.

谢谢.