小编Att*_*áth的帖子

无效的Resx文件.无法加载类型错误为什么?

我在代码上遇到设计器错误:

组件我愿意为以下内容定义属性列表:

using System.Collections.Generic;
using System.ComponentModel;
using System.Windows.Forms;

namespace TestProjectForProperty.Test
{
    public class MyTreeView : TreeView
    {
        private List<TypeDescriptorBase> _descriptorsAvailable = new List<TypeDescriptorBase>();

        [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
        public List<TypeDescriptorBase> DescriptorsAvailable
        {
            get { return _descriptorsAvailable; }
            set { _descriptorsAvailable = value; }
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

描述符本身:

using System;

namespace TestProjectForProperty.Test
{
    [Serializable]
    public class TypeDescriptorBase
    {
        public string Name { get; set; }

        public override string ToString()
        {
            return Name;
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

如果我尝试在表单上使用组件并将属性表或组件的构造函数中的任何项添加到DescriptorsAvailable属性,我会收到以下错误

错误1无效的Resx文件.无法加载类型System.Collections.Generic.List`1 [[TestProjectForProperty.Test.TypeDescriptorBase,TestProjectForProperty,Version = 1.0.0.0,Culture = neutral,PublicKeyToken = null]],mscorlib,Version = …

.net c# designer properties visual-studio-2010

4
推荐指数
2
解决办法
9700
查看次数

Lexer的前瞻如何与ANTLR3和ANTLR4中的贪婪和非贪婪匹配一起工作?

如果有人能够从前瞻性关系背后的混淆中清除我的想法,那就是涉及格雷斯/非贪婪匹配的令牌化,我会非常高兴.这是一个稍长的帖子,因为它跟随我的思考过程.

我正在尝试编写antlr3语法,允许我匹配输入,如:

"identifierkeyword"

我在Antlr 3.4中提出了类似的语法:

KEYWORD: 'keyword' ;

IDENTIFIER
: 
  (options {greedy=false;}: (LOWCHAR|HIGHCHAR))+ 
;

/** lowercase letters */
fragment LOWCHAR
:   'a'..'z';
/** uppercase letters */
fragment HIGHCHAR
:   'A'..'Z';

parse: IDENTIFIER KEYWORD EOF;
Run Code Online (Sandbox Code Playgroud)

然而,它抱怨它永远不会匹配IDENTIFIER这种方式,我真的不明白.(以下替代方案永远不能匹配:1)

基本上我试图指定试图匹配(LOWCHAR | HIGHCHAR)非贪婪方式的词法分析器,因此它停在KEYWORD前瞻.到目前为止我读到的关于ANTLR词法分析器的内容应该是词法规则的某种优先权.如果我首先在词法分析器语法中指定KEYWORD词法分析器规则,那么之后的任何词法分析器规则都不应该与消耗的字符匹配.

经过一些搜索后我明白这里的问题是它无法以正确的方式对输入进行标记,因为例如输入:"identifierkeyword"首先出现"标识符"部分,因此当没有KEYWORD时它决定开始匹配IDENTIFIER规则令牌匹配了.

然后我尝试在ANTLR 4中编写相同的语法,以测试新的预装功能是否可以匹配我想要的,它看起来像这样:

KEYWORD: 'keyword' ;

/** lowercase letters */
fragment LOWCHAR
:   'a'..'z';
/** uppercase letters */
fragment HIGHCHAR
:   'A'..'Z';

IDENTIFIER
: 
  (LOWCHAR|HIGHCHAR)+?
;

parse: IDENTIFIER KEYWORD EOF;
Run Code Online (Sandbox Code Playgroud)

对于输入:"identifierkeyword"它会产生此错误:第1行:1不匹配的输入'd'期待'关键字'

它将字符'i'(第一个字符)与IDENTIFIER标记匹配,然后解析器需要一个KEYWORD标记,他不会这样做.

对于词法分析器的非贪婪匹配是不是应该匹配,直到前瞻中有任何其他可能性?难道它不应该期待IDENTIFIER可以包含KEYWORD并以这种方式匹配吗?

我真的对此感到困惑,我看过Terence Parr介绍ANTLR4的新功能的视频,他谈到了在实际匹配规则的同时监视所有"正确"解决方案的预先运行的线程.我认为它也适用于Lexer规则,其中用于标记输入"identifierkeyword"的可能正确解决方案匹配IDENTIFIER:"identifier"并匹配KEYWORD:"keyword"

我觉得我脑子里有很多关于非贪婪/贪婪匹配的错误.有人可以解释一下它是如何工作的吗?

在这之后我在这里发现了一个类似的问题:ANTLR尝试在更长的令牌中匹配令牌,并制作了与之对应的语法:

parse
:   
  identifier …
Run Code Online (Sandbox Code Playgroud)

parsing antlr lexer antlr3 antlr4

1
推荐指数
1
解决办法
4699
查看次数

标签 统计

.net ×1

antlr ×1

antlr3 ×1

antlr4 ×1

c# ×1

designer ×1

lexer ×1

parsing ×1

properties ×1

visual-studio-2010 ×1