유니 코드 응용 프로그램 용으로 DevExpress TdxDBGrid를 마이그레이션하려고하며 유니 코드가 아닌 TStringList가 없으면 마이그레이션을 완료하는 데있어 유일한 장애물입니다. JcLAnsiString (Jedi/Jcl 오픈 소스 프로젝트의)에서 TAnsiStringList를 사용하려고 시도했지만 작동하는 동안 Jedi/Jcl 프레임 워크에 너무 많은 종속성이 포함됩니다. 일반적으로 내 계획은 유니 코드 데이터 작업을 위해 마이그레이션 된 TdxDBGrid를 사용하는 것이지만 북마크, 선택된 행 등을 저장하는 것과 같은 내부 작업에는 TAnsiStringList가 필요합니다.유니 코드가 아닌 호환성을위한 델파이 XE의 Ansi TStringList
가벼운 비 유니 코드 TStringList (의존성이 더 적은)가 있습니까?
사용하는 TStringList의 기능이 확실하지 않지만 작업에 TStringList 대신 일반 TList<AnsiString>을 사용해 볼 수 있습니다. String 대신 AnsiString 유형을 사용하는 유일한 이유가 내부적으로 문자열을 유지하는 경우라면 충분할 것입니다.
나는'TdxDBGrid'가 내부적으로'TStringList'를 사용한다는 점에서이 질문을 이해합니다. 그렇다면'TdxDBGrid'가'TStringList' 대신'TList
@TLama : 안녕하세요, TAnsiStringList를 사용해 보았습니다. 그래서 그는 확실히 소스 코드를 가지고 거기에 변화를줍니다. 내부적으로 문자열의 저장처럼 사용된다면, TStringList를 다른 것으로 대체하는 것으로 충분할 것입니다. JEDI에서 이미 TAnsiStringList로 변경 한 경우 JounI없이 TAnsiStringList = List
그 구성 요소가 내부적으로'string'을 기본 유형 (아래의 Delphi 2009에서 AnsiString과 위의'UnicodeString'에 매핑 됨)으로 사용하고 일반적인'TStringList' 클래스를 사용하면 ('string'과 동일한 intenal 매핑을가집니다. 유형), 아무 것도 할 필요가 없습니다. 이런 경우에는 내부적으로'string' 타입을 사용하고 문자열 목록을 ANSI로 설정하면 유니 코드를 잃어 버리게되므로 더 심각합니다. – TLama
'TStringList'에 어떤 문제가 있는지 알 수 없습니다. 왜 그걸 사용하지 않니? 그 외에, 당신이 정말로 필요하다고 가정 할 때,'TStringList'에서 코드를 가져 와서'string'을'AnsiString'으로 대체하는 것이 얼마나 힘들 수 있습니까? 확실히 당신은 그 일에 달려 있습니다. –
애플리케이션을 유니 코드 델파이로 마이그레이션 할 때'TdxDBGrid'에'AnsiString' 문자열 목록이 필요합니까? 나는 왜 개발자들이 그렇게할지 모른다. IMHO 그냥'TStrings' 추상 클래스가 필요하고 전체 구성 요소는 * 유니 코드 준비 *이고'AnsiString' 문자열 목록을 사용하는 것은 잘못된 것입니다. 그러나 그것은 모두 제 추측입니다 (그리고 그 구성 요소의 좋은 설계에 대한 희망). – TLama
ANSI 버전의'TStrings '에 대한 유일한 응용 프로그램은 메모리에 저장된 많은 양의 ANSI 텍스트입니다. – OnTheFly