VS2008의 프로젝트 파일의 리소스는 양식 디자이너에 의해 창의적으로 "재사용"되어 피할 수 있습니까?

Question

Visual Studio 2008의 프로젝트에는 일부 지역 버전이있는 일부 자동 생성 리소스 파일이 있으며이 지역 버전 중 하나에는이 경우 비어있는 문자열이 있습니다.

더 명확합니다. 많은 문자열 리소스가있는 핵심 리소스 파일이 있습니다. 그런 다음 4 개의 다른 현지화 된 버전의 thisfile을 가지고 있으며, 다른 현지화 된 파일 중 하나에서 문자열 중 하나에 빈 값이 주어집니다.

문제는 이제 Form Designer가 문자열에 대한 리소스를 찾는 것에 대해 매우 기뻐하며, 빈 문자열에 대해이 리소스를 재사용하기 위해 아무것도 멈추지 않을 것이라는 점입니다.

예를 들어, 어떤 이유로 컨트롤의 속성이 기본값으로 지정되지 않은 경우 (따라서 비어있는 경우에도 코드로 코드로 직렬화됩니다). C# 코드.

문제는 현지화 된 버전을 참조하고 코드로 컴파일되지 않는다는 것입니다.

약식 코드 예는 다음과 같습니다.

this.rpAllFields.KeyTip = 
  global::namespaces.SystemMessagesResources_sv_SE.
    dash_red_shift_info_description;

이 경우 dash_red_shift_info_description SV-SE 로케일에 대한 값이 없으므로 디자이너는 코드에서 빈 문자열을 볼 때 해당 리소스에 연결하려고합니다. 그러나 SystemMessagesResources_SV_SE는 기존 클래스가 아니지만 SystemMessagesResources 리소스 파일의 스웨덴 인형 버전의 생성 된 클래스 이름 인 것 같습니다. ~이다 수업에 편집되었습니다.

피할 수 있습니까? 우리는 양식 파일에서 무언가를 변경할 때마다 검색/교체에 지치고 있으며, 이런 일이 발생하는 일이 끝나는 일이있을 것이라고 확신합니다. 이 원인을 스스로 찾을 수는 없습니다.

위의 코드는 리소스를 제거하면 다음과 같이 읽습니다.

this.rpAllFields.KeyTip = "";

Answer 1

모든 로케일에 대해 ""로 정의 된 String Resource Belly_string을 만들 수 있습니다. 첫 번째 리소스로 만들면 양식 디자이너는 (희망적으로) 항상 양식을 뿌릴 값으로 선택합니다. 이런 식으로 적어도 당신은 그 목적을 위해 지정된 문자열을 사용하게됩니다.

Answer 2

리소스 파일의 빈 문자열로 인해 문제가 발생하는 경우 공간으로 만드는 효과는 무엇입니까? 따라서 ""리소스 파일은 ""대신 ""대신 "" " 그것이 최선의 솔루션인지는 모르겠지만 디자이너가 해당 리소스를 기본 빈 문자열로 사용하는 것을 막는 지 알고 싶습니다. 그러나 그것이 어떻게 사용되는지 모르면, 정의되지 않은 값을 갖는 것이 공간으로 정의되는 것에 어떤 영향을 미치는지 잘 모르겠습니다 ...

Answer 3

값이 빈 문자열 인 리소스가 얼마나 필요합니까? 일부 리소스 키가 지원되는 언어 (일부 UI 요소에 문자열 연결을 사용하는 경우)의 일부 리소스 키가 공백에 해당 해야하는 다국어 시나리오를 상상할 수 있습니다.

그러나 내 시나리오가 이와 같은 것이 아니라면 빈 문자열로 리소스 항목을 긁어 낼 것입니다. "어쨌든 어떤 독립형 UI 텍스트가 공백으로 번역 되는가?"라고 말하고 싶습니다.

실제로 비워지기 위해 리소스가 필요하다면 약간 사례, (한 언어로 된 기사를 나타내고 다른 단어에 동등한 단어가 존재하지 않는 경우), 나는 다른 방식으로 같은 효과를 만들 수 있는지 알아 보려고 노력할 것입니다.

Answer 4

생성 된 리소스 파일 및 코드 샘플이 좋습니다.

그리고 당신이 말하는 것은 : 당신은 당신의 네임 스페이스에 빈 문자열 리터럴 정의를 가지고 있지만 (첫 번째 발견) 문제를 일으키고 있습니까? 항상 비어 있지 않습니까? 코드를 컴파일하면 공간을 절약하기 위해 이와 같은 기발한 일을합니다. 현대 자동 조립 파일 빌드를 위해 CodeBehind를 사용하여 XAML 파일을 생성 할 때 비슷한 문제를 해결했습니다. 컴파일러는 '차이가 없지만 리터럴의 이름을 바꾸기 때문에 우리에게는 그렇게했습니다. (다른 곳에서 사용되었습니다).

이 문제를 해결하기 위해 우리는 네임 스페이스에서 이러한 프리미티브에 이름이 지정된 유형을 사용했으며 그 글로벌을 만들었습니다. 여기서 보는 것은 글로벌 네임 스페이스가 공백을 채우고 있다는 것입니다. 모든 널 문자열을 평가하는 아래의 '아래'를 갖고 싶을 수도 있습니다.

나는 1 년 넘게 이것과 함께 일하지 않았으므로 문구가 가난하다면 용서해 주지만, 내 말은 : XML을 생각하십시오. 속성에서 명시 적으로 네임 스페이스를 사용하거나 XAML에 첨부 된 속성과 같이 더 낮게 할당해야합니다.

나는 이것이 도움이되기를 바랍니다.