MQL로 작성된 UI 갤러리 - 페이지 24

 
hini #:
컴파일 시 생성되는 5,000개 이상의 경고, 그 중 상당수가 마크업 언어 파일에 있는 경고를 어떻게 제거할 수 있을까요?
불가능합니다. 마크업 코드를 문자열 배열로 작성하기 때문에 기술적으로 피할 수 없습니다. 이 데이터 유형은 일반적으로 모든 값과 단어를 작성하는 데 적합합니다.

결국 생성자가 키워드, 이름, 숫자 값을 완벽하게 구분할 수 있기 때문에 문제가 되지 않습니다.

이 접근 방식으로 인한 데이터 손실은 없습니다.
 
이론적으로는 각 숫자 값 앞에 (int) 또는 (double)을 쓸 수 있지만, 이는 사용자에게 맡기겠습니다.
 
"컴파일러의 목을 밟아야" 하지만 결국에는 우리가 이깁니다). 별거 아닙니다.


참고로 말씀드리자면. 저는 프로그래밍 규칙과 컴파일러의 경고를 존중하지만 이 경우에는 더 나은 해결책을 찾지 못했습니다. 어떤 사람들은이 접근 방식을 좋아하지 않을 수도 있지만 이것이 가장 최적이라는 것을 알고 있습니다. 그리고 무해합니다.
 
내일 업데이트를 게시하고 마침내 자신 만의 인터페이스를 만들고 싶은 사람들이 게시 할 수 있기를 바랍니다. 최선을 다하겠습니다.
 
Реter Konow 컴파일러 경고를 존중하지만이 경우 더 나은 솔루션을 찾을 수 없었습니다. 일부 사람들은이 접근 방식을 좋아하지 않을 수도 있지만 이것이 가장 최적이라는 것을 알고 있습니다. 그리고 무해합니다.
작은 이야기:

마크 업 코드를 어디에 작성해야하는지에 대한 질문이 생겼을 때 문자열 배열 또는 파일이라는 두 가지 주요 옵션에 직면했습니다. 장단점을 따져본 결과, 여러 가지 이유로 배열이 훨씬 낫다는 결론을 내렸습니다. 첫째, 생성자 코드를 통해 배열 내용을 즉시 초기화하고 처리할 수 있습니다. 둘째, 생성자/엔진에서 컨트롤의 개별 어트리뷰트 및 속성에 빠르게 액세스하여 필요한 경우 읽기/쓰기가 가능합니다(파일이라면 큰 문제가 될 수 있습니다). 셋째, 사용자 정의 OnChartEvent() 이벤트를 통해 배열을 리소스로 전송하는 것이 훨씬 쉽습니다. 이것이 바로 배열을 선택한 이유입니다. 그리고 경고... 뭐, 어쩔 수 없죠. 목표를 달성하려면 항상 무언가를 희생해야 합니다.

 
위 텍스트 수정: 리소스가 아닌 구성된 문자열 조각으로 전달합니다.
 
마크업을 텍스트 파일로 작성할 수 있다는 생각의 '관 뚜껑'에 마지막 못을 박는 총체적인 이유입니다:

.txt 파일은 심각한 오타가 없는지 확인하기 위해 컴파일할 수 없습니다. 즉, 사용자가 쉼표, 따옴표, 공백 등으로 무언가를 심하게 엉망으로 만들면 컴파일러에서 이를 알아차리지 못한다는 뜻입니다.

인터페이스 구축에 실패한 후에야 코드를 잘못 입력했다는 사실을 깨닫고 마지막 오타까지 모두 검색하여 찾아야 합니다. 하나라도 놓치면 절차를 다시 수행해야 합니다.

이는 컴파일러 경고가 없는 것에 비해 엄청나게 비싼 대가입니다.

그렇기 때문에 MQL에서는 마크업 코드에 문자열 배열을 사용하는 변형은 대안이 없으며 사용할 수 없습니다. 그리고 컴파일러 경고는 당연한 것으로 받아들여야 합니다.
 
추신: 컴파일러는 키워드의 철자가 틀린 경우에도 경고를 표시합니다. 때때로 인텔리센스 기능이 도움이 됩니다. .txt 파일에서는 키워드 철자가 틀리면 알 수 없습니다. 따라서 파일은 배열에 비해 실질적인 이점이 없습니다.

이 특별한 경우에 컴파일러 경고를 제거해서는 안되는 이유를 자세히 설명해 드렸기를 바랍니다.

여러분, 좋은 하루 되세요.

 
Реter Konow 컴파일러 경고를 제거해서는 안 되는 이유를 자세히 설명해 드렸기를 바랍니다.

안녕하세요 여러분.

네, 알겠습니다.
 
생성자 코드의 핵심이 되는 부분인가요?