이미 실행 중인 표시기 내부에 전처리된 데이터를 전송할 필요가 있습니다. 그래프 텍스트를 글로벌 데이터 저장소로 사용하기로 결정했습니다. 물체. 나는 약속 그래프를 이해합니다. 개체가 다르며 다른 대안이 있으면 기꺼이 듣겠습니다.
그러나 여기서 나는 언어의 또 다른 한계를 발견했습니다. 문자열 자체는 거의 무한한 문자 길이를 지원합니다. 글쎄, 아마도 제한은 일반적으로 배열의 제한 영역 어딘가에 있을 것입니다. 그래프 매개변수로 전달된 문자열입니다. 개체는 63자로 제한됩니다. 결과적으로 배열을 문자열로 전송하려면 많은 그래프가 필요합니다. 개체(예, 암호화를 사용한다고 말하는 것을 잊었습니다. 그래서 찌르기의 정보는 원래 유형과 거의 같은 공간을 차지합니다). 이제 현재 63개의 문자를 사용하여 하나의 개체를 통해 15개의 시간/가격 쌍만 전송하는 것으로 나타났습니다.
따라서 질문: 미래에 언어가 그래프 텍스트의 길이에 대한 제한을 제거할 것이라고 기대할 수 있습니까? 개체 또는 표시기 흐름 내부에 데이터를 전달하는 메커니즘을 도입? 후자가 바람직할 것입니다.
어떤 기적들이 있습니까? 어느 한 쪽이 다른 쪽보다 크다는 것을 알 수 있는 순간은 단 한 번도 없었습니다.
여기 내가 디 .... 실제로 코드에 오류가 있지만 내 두뇌를 건드리는 중이었습니다!
덕분에!
여기 내가 디 .... 실제로 코드에 오류가 있지만 내 두뇌를 건드리는 중이었습니다!
올바른 철자는 "e"입니다.
사소하지만 여전히
경고: 유형 변환으로 인한 데이터 손실 가능성
뭐가 문제 야? (5.00.412)
사소하지만 여전히
정수 속성은 항상 반환되며 자신의 캐스팅 을 수행하면 경고가 표시되지 않습니다.
사소하지만 여전히
경고: 유형 변환으로 인한 데이터 손실 가능성
뭐가 문제 야? (5.00.412)
SymbolInfoInteger 함수는 long을 반환합니다. int를 얻으려면 다음을 수행해야 합니다.
사소하지만 여전히
경고: 유형 변환으로 인한 데이터 손실 가능성
뭐가 문제 야? (5.00.412)
검사 결과는 정확하지만 로그에는 없습니다!
어떤 기적들이 있습니까? 어느 한 쪽이 다른 쪽보다 크다는 것을 알 수 있는 순간은 단 한 번도 없었습니다.모든 TF와 기호에 상관없이.
코드를 주의 깊게 살펴보고 오류를 수정합니다.
이미 실행 중인 표시기 내부에 전처리된 데이터를 전송할 필요가 있습니다. 그래프 텍스트를 글로벌 데이터 저장소로 사용하기로 결정했습니다. 물체. 나는 약속 그래프를 이해합니다. 개체가 다르며 다른 대안이 있으면 기꺼이 듣겠습니다.
그러나 여기서 나는 언어의 또 다른 한계를 발견했습니다. 문자열 자체는 거의 무한한 문자 길이를 지원합니다. 글쎄, 아마도 제한은 일반적으로 배열의 제한 영역 어딘가에 있을 것입니다. 그래프 매개변수로 전달된 문자열입니다. 개체는 63자로 제한됩니다. 결과적으로 배열을 문자열로 전송하려면 많은 그래프가 필요합니다. 개체(예, 암호화를 사용한다고 말하는 것을 잊었습니다. 그래서 찌르기의 정보는 원래 유형과 거의 같은 공간을 차지합니다). 이제 현재 63개의 문자를 사용하여 하나의 개체를 통해 15개의 시간/가격 쌍만 전송하는 것으로 나타났습니다.
따라서 질문: 미래에 언어가 그래프 텍스트의 길이에 대한 제한을 제거할 것이라고 기대할 수 있습니까? 개체 또는 표시기 흐름 내부에 데이터를 전달하는 메커니즘을 도입? 후자가 바람직할 것입니다.