Canvas에서 크라우드소싱 프로젝트 만들기 - 페이지 4

 
Vasiliy Sokolov :

Anatoly의 기사 이후 프로필에서만 동일한 계란을 다시 만드는 것은 적어도 이상한 취미 인 것 같습니다. 그래픽은 MT와 전혀 관련이 없는 주제입니다.

  • 사용자는 그래픽 인터페이스가 필요하지 않습니다. 결과적으로 GUI는 수익을 창출할 수 없으며 개발은 결코 성과를 거두지 못할 것입니다.
  • 실력을 키우고 싶다면 당장 후배로 취직하는 게 낫다. 그래서 당신은 즉시 최소한의 돈을 받기 시작하고 천천히 당신의 기술을 올릴 것입니다.
  • 타겟층이 너무 좁습니다. 누가 도서관을 필요로 합니까? - 소수의 프로그래머를 제외하고는 아무도 없었고, 심지어 그 프로그래머들도 오래전에 필요한 모든 라이브러리를 작성했습니다. 예를 들어, 제 자신의 그래픽 라이브러리가 최대 2개 있습니다.

여기에 있는 사람들을 가르치는 것은 내가 아니지만 조언을 드릴 수 있습니다. 여러분, 화약 냄새를 맡으십시오. 사용자와 함께 일하는 방법을 배웁니다. 그들의 심리를 알아보십시오. 아이디어를 수익화하는 방법을 배웁니다. 그런 다음 재빨리 하늘에서 땅으로 내려오면 완전히 다른 방식으로 논쟁하게 될 것입니다. 나는 또한 한때 특별하고 아름다운 아이디어를 믿었지만 이 모든 것은 말도 안 되는 일이며 작동하지 않습니다. 당신이 여기서 논의하는 것은 당신 외에는 누구에게도 쓸모가 없습니다.

+1

소위 "상인"의 대부분은 아름다움이 필요하지 않고 전리품이 필요합니다. 적어도 달의 세 번째 단계에서 가격을 계산하기 위한 하이퍼 슈퍼 기술을 갖춘 고문은 아름답게 들리고 자랑할 수 있고 희망이 있기 때문입니다. 기술의 기적..

그리고 극소수의 사람들은 미인과 함께 데모나 실생활에서만 작동하는 성경을 필요로 합니다.

 

Vladimir Pastushak :

그리고 극소수의 사람들은 미인과 함께 데모나 실생활에서만 작동하는 성경을 필요로 합니다.

반복합니다. 우리는 성경을 만들지 않습니다.

우리는 문제를 해결합니다.

이 분기는 측정을 위한 것이 아니라 특정 문제를 해결하기 위한 것입니다.

Vladimir, 당신은 부정적인 의견 없이 시청하거나 가입합니다. 그러나 이 스레드에서는 OOP나 달의 위상을 배우지 않을 것입니다.

 
o_O :

반복합니다. 우리는 성경을 만들지 않습니다.

우리는 문제를 해결합니다.

이 분기는 측정을 위한 것이 아니라 특정 문제를 해결하기 위한 것입니다.

Vladimir, 당신은 부정적인 의견 없이 시청하거나 가입합니다. 그러나 이 스레드에서는 OOP나 달의 위상을 배우지 않을 것입니다.

OOP를 잘 몰라서 가입할 수 없습니다.

나는 단지 당신의 시간을 절약하기 위해 노력했습니다.

옵저버 곁으로 가는데...

 
Zorro :
그러나 입력 필드 의 문제는 우리가 사용할 수 있는 것을 사용하는 방법에 대한 좋은 아이디어가 아직 없다는 것입니다.

이제 IMHO에서는 자신만의 GUI 키보드를 그려야만 본격적인 EDIT를 할 수 있지만 언어 지원이 어렵고, 마우스로 텍스트를 입력하는 것도 불편합니다...

입력을 방해하지 않도록 이벤트 또는 차트 작업에 필요한 추가 기능은 무엇입니까?

SD에 개선을 요청하십시오.

 
Vladimir Pastushak :

예를 들어, 나는 다음과 같은 것을 이해하지 못합니다.

a >> 0 << 0 ;                       //нет сообщения об ошибке 
a. operator >>( 0 ). operator <<( 0 ); //error: правомерно  

이것을 어디에 적용하고 일반적으로 이해하는 방법을 배우고 이해할 수 있는 문서 또는 다른 곳에서 저를 보여주십시오 ...

코드 관련 - 서비스 데스크에 문의하십시오. 그들이 무슨 말을 할지 궁금하다. 학습과 이해에 관해서는 MQL이 C++의 예를 따라 작성되었으므로 관련 문서를 확인하십시오. 많은 문서가 있습니다. 그러나 원칙적으로 OOP에 유사한 분기가 이미 있지만 이러한 질문으로 다른 스레드를 열 수 있습니다.
 
Vasiliy Sokolov :

... 그래픽은 MT와 전혀 관련이 없는 주제입니다...

따라서 그래픽만 있는 것은 아닙니다. 여기에서 제공되는 것은 최고 품질의 그래픽 인터페이스를 생성하는 것을 가능하게 할 것입니다. 표준 그래픽 개체의 기본 요소에 자신을 제한하면 많은 것이 부족하다는 결론에 도달합니다. 또한 경우에 따라 간섭할 수 있는 매우 많은 수의 그래픽 개체 로 작업해야 합니다.

어떤 사람들은 어떤 종류의 오락이나 게임에 시간을 보내지만 오락이 일부 흥미롭고 유용한 작업에 대한 해결책인 사람들이 있습니다. 이 포럼의 많은 사람들은 일반적으로 공허한 잡담에 시간을 낭비합니다.

여기에 참여하고 싶지만 지금은 지붕 너머로 내 자신의 작업이 있습니다. )

 
포럼의 친애하는 회원 여러분, 여기에서 실제로 수행되도록 제안된 것이 무엇인지 이해하는 것은 매우 흥미롭습니다. 이를 통해 "매우 고품질" 그래픽 인터페이스를 만들 수 있습니다. 솔직히 말해서, 나는 전혀 이해하지 못했다.
 
내가 틀렸다면 정정해 주세요. 그러나 작업의 본질은 그림에 세부 사항을 그려서 가능한 한 적은 수의 그래픽 개체를 사용하여 컨트롤 을 구현하는 것입니까? 그렇다면 슬라이더는 예를 들어 완전히 그려진 경우 어떻게 작동합니까? 최소한 두 개의 상호 작용하는 개체가 필요합니다...
 
Реter Konow :

가능한 한 적은 수의 그래픽 개체 사용

적지만 전혀 없음(모든 것이 그려지는 bitmap_label 제외)

예를 들어 슬라이더가 완전히 그려진 경우 슬라이더는 어떻게 작동합니까? 최소한 두 개의 상호 작용하는 개체가 필요합니다...

슬라이더에서 누른 마우스를 말씀하시는 건가요?

----

지금까지 Zorro 가 쓴 한 가지 문제가 있습니다. 바로 입력 필드 입니다.

차트 이벤트는 모든 키에 대한 코드를 제공하지 않습니다. 또한 차트는 공백을 가로채고 들어갑니다.

 
o_O :

적지만 전혀 없음(모든 것이 그려지는 bitmap_label 제외)

슬라이더에서 누른 마우스를 말씀하시는 건가요?

----

현재까지 Zorro 가 쓴 한 가지 문제가 있습니다. 바로 입력 필드 입니다.

차트 이벤트는 모든 키에 대한 코드를 제공하지 않습니다. 또한 차트는 공백을 가로채고 들어갑니다.

정확히는 마우스에 관한 것이 아닙니다.

기본적으로 완전히 그려진 "슬라이더"컨트롤의 메커니즘을 이해하지 못합니다 .

슬라이더의 주요 기능은 두 점(A와 B) 사이의 거리를 주어진 비율과 단계를 사용하여 사용자 매개변수 값으로 변환하는 것입니다.

내 구현에서 점 A와 B는 슬라이더 트랙의 X 좌표(원점)와 슬라이더 슬라이더의 X 좌표라는 두 개체의 위치로 표시됩니다. 이 함수는 두 점 사이의 거리를 측정하고 이를 매개변수 값으로 변환합니다.

두 개체가 그림에서 병합되면 점 A와 점 B의 위치는 어떻게 됩니까? 이 경우 이러한 점은 단순히 이미지의 픽셀입니다.

픽셀은 점 사이의 거리를 측정하기 위해 좌표를 어떻게 반환합니까?

슬라이더를 이동하면 그림이 어떻게 변합니까?

슬라이더 그립의 정확한 위치는 (x 좌표를 기준으로) 어떻게 반환되고 움직임의 경계는 고정됩니까?

그리고 슬라이더 위치가 스트로크의 한계를 벗어날 때 어떻게 수정됩니까?

이러한 모든 메커니즘은 슬라이더 구현에서 작동하며 제안된 기술은 나에게 명확하지 않지만 이러한 방식으로 개체 수를 크게 줄일 수 있음을 이해합니다.