이 모든 것이 일반적인 스타일 설정으로 이동합니다. 거기에는 링크 버튼, 호버 버튼, 클릭 버튼 , 그냥 버튼과 같은 특정 순간이 있습니다. 그리고 매 순간마다 그들은 일반적으로 자신의 스타일을 만들거나 혼합합니다.
사실, 나는 항상 버튼에 의한 실행 코드 구성의 구성이 정확히 어떻게 수행되는지 이해하지 못했습니다. 시각적이기도 했다는 것. 그리고 그들의 코드로 오류를 검사합니다.
그러한 작업의 눈에 띄는 예는 메뉴를 만들기 위해 메뉴를 만드는 것입니다. 저것들. 그래픽으로 하면 코드 삽입으로 왼쪽 또는 오른쪽 메뉴를 만들 수 있습니다. 즉, 날아가지 않습니다.
아니면 코드에서 버튼을 생성하는 것뿐인가요....?
스타일 사용자 정의는 편집의 시작일 뿐입니다. 또한, 기회의 수는 눈사태처럼 증가할 것입니다. 주요 작업은 마크업 언어의 기본 기능을 비주얼 편집기로 끌어오는 것입니다. 이렇게 하는 것은 어렵지 않습니다. 시각적인 수준에서 초음속 장벽을 극복하는 것과 같은 특정 돌파구가 있다고 말하고 싶습니다. 설명하기 어렵습니다... - 마치 가능성이 자물쇠와 열쇠로 잠겨 있고, 이제 비주얼로 전환할 때 문이 열리고 더미에 떨어졌습니다. 구현만 하면 됩니다.
스타일 사용자 정의는 편집의 시작일 뿐입니다. 또한, 기회의 수는 눈사태처럼 증가할 것입니다. 주요 작업은 마크업 언어의 기본 기능을 비주얼 편집기로 끌어오는 것입니다. 이렇게 하는 것은 어렵지 않습니다. 시각적인 수준에서 초음속 장벽을 극복하는 것과 같은 특정 돌파구가 있다고 말하고 싶습니다. 설명하기 어렵습니다... - 마치 가능성이 자물쇠와 열쇠로 잠겨 있고, 이제 비주얼로 전환할 때 문이 열리고 더미에 떨어졌습니다. 구현만 하면 됩니다.
코드는 기본적으로 생성되지 않습니다. 디지털 설명의 요소를 포함하는 커널이 생성됩니다. 사용자 응용 프로그램에 연결된 엔진에서 읽고 양방향 통신을 관리합니다.
원하는 것: 기본 스타일 생성 및 편집, 기본 스타일 생성. 버튼 스타일을 별도로 사용자 정의합니다. 현대적인 방향에서 무언가를 기반으로 한 스타일 템플릿에 더 중점을 두어야 합니다.
즉석에서 사용자 파일의 코드를 최소한 일부 편집하는 기능. 예를 들어 특정 클래스에 대한 호출이나 표시해야 하는 목록이 있습니다. 따라서 추가적인 후처리를 위한 구체적인 대응에 대한 기준이 있어야 한다.
시각적 편집의 가능성이 더 커야 한다는 것은 논리적이지만, 올바른 버튼을 사용하고 거기에 메뉴를 확실하게 만드는 것이 논리적이라고 생각하는 첫 번째 단계일 뿐입니다. 코드는 일반적으로 독립적으로 만드는 것이 더 쉽습니다. 미래에는 MT에서의 작업뿐만 아니라 필요할 수도 있습니다. 따라서 파일이 연결됩니다. 글쎄, 우리가 시장을 위해 그것을한다면 적어도 포함에서.
일반적으로 이러한 방향에서 각각의 새로운 단계는 코드에서 훨씬 더 큰 작업으로 이어지며 특정 시간에 모든 것을 수행하는 것이 현실적이지만 실제로는 훨씬 더 오래 걸립니다. 그리고 항상 그럴 것입니다. 기능은 완전히 작동하는 첫 번째 버전이 릴리스된 후에만 비유적으로 증가할 것입니다.
원하는 것: 기본 스타일 생성 및 편집, 기본 스타일 생성. 버튼 스타일을 별도로 사용자 정의합니다. 현대적인 방향에서 무언가를 기반으로 한 스타일 템플릿에 더 중점을 두어야 합니다.
즉석에서 사용자 파일의 코드를 최소한 일부 편집하는 기능. 예를 들어 특정 클래스에 대한 호출이나 표시해야 하는 목록입니다. 적절하게는 추가 후처리를 위한 구체적인 대응에 대한 기준이 있어야 합니다.
시각적 편집의 가능성이 더 커야 한다는 것은 논리적이지만, 올바른 버튼을 사용하고 거기에 메뉴를 확실하게 만드는 것이 논리적이라고 생각하는 첫 번째 단계일 뿐입니다. 코드는 일반적으로 독립적으로 만드는 것이 더 쉽습니다. 미래에는 MT에서의 작업뿐만 아니라 필요할 수도 있습니다. 따라서 파일이 연결됩니다. 글쎄, 우리가 시장을 위해 그것을한다면 적어도 포함에서
스타일 템플릿 저장에 대해 생각하겠습니다. 마크업 언어에서는 이것이 쉬웠습니다. 거기에서 속성 체인은 요소에서 요소로 간단하게 복사할 수 있으며 원하는 모양을 취했습니다. 여기에는 직접 연결이 없지만 수행하는 데 문제가 무엇입니까? 더 좋고 더 쉬울 수 있다고 생각합니다. 저장된 템플릿 속성 값으로 스타일을 가져오는 것과 같은 것...
사용자 파일 편집 가능성에 관해서는 그것이 무엇에 관한 것인지 잘 이해하지 못했습니다. 예를 들면...
연결에 필요한 파일이 인쇄됩니다. 두 가지가 있습니다. 엔진에 대한 부팅 정보와 사용자 응용 프로그램에 대한 API가 있습니다. 요소와 "통신"하도록.
이 모든 것이 일반적인 스타일 설정으로 이동합니다. 거기에는 링크 버튼, 호버 버튼, 클릭 버튼 , 그냥 버튼과 같은 특정 순간이 있습니다. 그리고 매 순간마다 그들은 일반적으로 자신의 스타일을 만들거나 혼합합니다.
사실, 나는 항상 버튼에 의한 실행 코드 구성의 구성이 정확히 어떻게 수행되는지 이해하지 못했습니다. 시각적이기도 했다는 것. 그리고 그들의 코드로 오류를 검사합니다.
그러한 작업의 눈에 띄는 예는 메뉴를 만들기 위해 메뉴를 만드는 것입니다. 저것들. 그래픽으로 하면 코드 삽입으로 왼쪽 또는 오른쪽 메뉴를 만들 수 있습니다. 즉, 날아가지 않습니다.
아니면 코드에서 버튼을 생성하는 것뿐인가요....?
스타일 사용자 정의는 편집의 시작일 뿐입니다. 또한, 기회의 수는 눈사태처럼 증가할 것입니다. 주요 작업은 마크업 언어의 기본 기능을 비주얼 편집기로 끌어오는 것입니다. 이렇게 하는 것은 어렵지 않습니다. 시각적인 수준에서 초음속 장벽을 극복하는 것과 같은 특정 돌파구가 있다고 말하고 싶습니다. 설명하기 어렵습니다... - 마치 가능성이 자물쇠와 열쇠로 잠겨 있고, 이제 비주얼로 전환할 때 문이 열리고 더미에 떨어졌습니다. 구현만 하면 됩니다.
예정된 작업:
1. 창 추가.
2. 요소 삭제.
3. 새 도구 만들기 - 파란색 프레임.
4. 창 내부의 요소 복사.
5. 편집의 초점을 확장합니다.
6. 편집 대상 추가.
7. 저장된 프로젝트를 선택하여 불러옵니다.
8. 엔진 업그레이드.
...
//------------------------------------------------
코드는 기본적으로 생성되지 않습니다. 디지털 설명의 요소를 포함하는 커널이 생성됩니다. 사용자 응용 프로그램에 연결된 엔진에서 읽고 양방향 통신을 관리합니다.
스타일 사용자 정의는 편집의 시작일 뿐입니다. 또한, 기회의 수는 눈사태처럼 증가할 것입니다. 주요 작업은 마크업 언어의 기본 기능을 비주얼 편집기로 끌어오는 것입니다. 이렇게 하는 것은 어렵지 않습니다. 시각적인 수준에서 초음속 장벽을 극복하는 것과 같은 특정 돌파구가 있다고 말하고 싶습니다. 설명하기 어렵습니다... - 마치 가능성이 자물쇠와 열쇠로 잠겨 있고, 이제 비주얼로 전환할 때 문이 열리고 더미에 떨어졌습니다. 구현만 하면 됩니다.
예정된 작업:
1. 창 추가.
...
//------------------------------------------------
코드는 기본적으로 생성되지 않습니다. 디지털 설명의 요소를 포함하는 커널이 생성됩니다. 사용자 응용 프로그램에 연결된 엔진에서 읽고 양방향 통신을 관리합니다.
원하는 것: 기본 스타일 생성 및 편집, 기본 스타일 생성. 버튼 스타일을 별도로 사용자 정의합니다. 현대적인 방향에서 무언가를 기반으로 한 스타일 템플릿에 더 중점을 두어야 합니다.
즉석에서 사용자 파일의 코드를 최소한 일부 편집하는 기능. 예를 들어 특정 클래스에 대한 호출이나 표시해야 하는 목록이 있습니다. 따라서 추가적인 후처리를 위한 구체적인 대응에 대한 기준이 있어야 한다.
시각적 편집의 가능성이 더 커야 한다는 것은 논리적이지만, 올바른 버튼을 사용하고 거기에 메뉴를 확실하게 만드는 것이 논리적이라고 생각하는 첫 번째 단계일 뿐입니다. 코드는 일반적으로 독립적으로 만드는 것이 더 쉽습니다. 미래에는 MT에서의 작업뿐만 아니라 필요할 수도 있습니다. 따라서 파일이 연결됩니다. 글쎄, 우리가 시장을 위해 그것을한다면 적어도 포함에서.
일반적으로 이러한 방향에서 각각의 새로운 단계는 코드에서 훨씬 더 큰 작업으로 이어지며 특정 시간에 모든 것을 수행하는 것이 현실적이지만 실제로는 훨씬 더 오래 걸립니다. 그리고 항상 그럴 것입니다. 기능은 완전히 작동하는 첫 번째 버전이 릴리스된 후에만 비유적으로 증가할 것입니다.
원하는 것: 기본 스타일 생성 및 편집, 기본 스타일 생성. 버튼 스타일을 별도로 사용자 정의합니다. 현대적인 방향에서 무언가를 기반으로 한 스타일 템플릿에 더 중점을 두어야 합니다.
즉석에서 사용자 파일의 코드를 최소한 일부 편집하는 기능. 예를 들어 특정 클래스에 대한 호출이나 표시해야 하는 목록입니다. 적절하게는 추가 후처리를 위한 구체적인 대응에 대한 기준이 있어야 합니다.
시각적 편집의 가능성이 더 커야 한다는 것은 논리적이지만, 올바른 버튼을 사용하고 거기에 메뉴를 확실하게 만드는 것이 논리적이라고 생각하는 첫 번째 단계일 뿐입니다. 코드는 일반적으로 독립적으로 만드는 것이 더 쉽습니다. 미래에는 MT에서의 작업뿐만 아니라 필요할 수도 있습니다. 따라서 파일이 연결됩니다. 글쎄, 우리가 시장을 위해 그것을한다면 적어도 포함에서
스타일 템플릿 저장에 대해 생각하겠습니다. 마크업 언어에서는 이것이 쉬웠습니다. 거기에서 속성 체인은 요소에서 요소로 간단하게 복사할 수 있으며 원하는 모양을 취했습니다. 여기에는 직접 연결이 없지만 수행하는 데 문제가 무엇입니까? 더 좋고 더 쉬울 수 있다고 생각합니다. 저장된 템플릿 속성 값으로 스타일을 가져오는 것과 같은 것...
사용자 파일 편집 가능성에 관해서는 그것이 무엇에 관한 것인지 잘 이해하지 못했습니다. 예를 들면...
연결에 필요한 파일이 인쇄됩니다. 두 가지가 있습니다. 엔진에 대한 부팅 정보와 사용자 응용 프로그램에 대한 API가 있습니다. 요소와 "통신"하도록.
요소에 텍스트를 인쇄합니다.
그리드에 대해 생각하십시오 - 일종의 정렬/맞추기가 필요합니다. 세 가지 요소를 정확히 연속으로 배치하는 것은 이미 어렵습니다.
동의한다. 나는 그것에 대해 생각합니다.
그리드에 대해 생각하십시오 - 일종의 정렬/맞추기가 필요합니다. 세 가지 요소를 정확히 연속으로 배치하는 것은 이미 어렵습니다.
네, 이 전체 그리드는 최대 10배 ......
사용자의 관심을 볼 필요가 있습니다. 예를 들어, 즉석에서 하나 또는 다른 차트를 생성할 수 있다면 ... 예를 들어 최대값에 선을 그리는 식입니다.
지금까지 이것은 소프트웨어 디자인 의 저자에게 아주 좋은 교훈에 불과하기 때문입니다. 메뉴를 만드는 것만으로는 그다지 흥미롭지 않습니다. 예, 함수 호출은 버튼에서 이루어져야 합니다.
html에서 캔버스의 대중화를 고려하여 보편적인 것을 구현하는 데 스포츠적인 관심이 있습니다. 그냥 모든 것이 어떻게 든 작동합니다.
....
사실, 코드 생성으로 우리 자신을 제한하는 또 다른 옵션이 있습니다. Tipo는 버튼의 전체 레이아웃이 있는 inkludnik을 만들고 데이터를 입력하는 것만 남아 있습니다 ...... - 또한 옵션입니다. 추신: 가장 가깝고 실행 가능한 옵션
3월 3일까지 다음 작업 목록을 구현하는 목표를 설정했습니다.
1. 창 추가/제거.
2. 요소 삭제.
3. 새 도구 생성 - 파란색 프레임.
4. 창 내부의 요소 복사.
5. 편집의 초점을 확장합니다.
6. 편집 대상 추가.
7. 저장된 프로젝트 선택 및 불러오기 .
8. 엔진 업그레이드.
9. 그리드 및 자동 수정 요소 위치.
//------------------------------------------------
그런 다음 비주얼 편집기를 사용하여 Windows와 유사한 사용자 응용 프로그램 인터페이스를 만들 수 있습니다.
(ps. 간단한 요소 집합이 있습니다. 그 다음에는 표와 다양한 목록이 나옵니다.)
Peter는 Windows를 발명하고 썼습니다! 30년만 늦었어
거인의 발자취를 따라갑니다.)