[질문] 메뉴 컨트롤에 관련된 좋은 방법을 찾습니다. 아이디어가 필요해요~ (질문을 좀 더 구체적으로 고쳤습니다.)
글쓴이: kleinstein / 작성시간: 목, 2011/05/26 - 11:34오후
어느 한 프로그램이 여러가지 기능을 제공한다고 했을때.. (예를 들어 기능 A 부터 P 까지..)
기능 A 는 메뉴 a 를 통해서 실행되고,
기능 B 는 메뉴 b 를 통해서 실행되고,
...
기능 P 는 메뉴 p 를 통해서 실행되고,
이런 식입니다.
아마 대부분 이런경우가 아닌가 싶은데요.. 이런 경우 기능 A가 실행되는 동안 기능 F 가 실행될수 없다거나 실행되어서는 안되는 경우는..
메뉴 f에 대한 선택을 금지시키거나( 기능 A가 다 실행되면 다시 기능 F에 대한 메뉴f 가 활성화 되어야 겠지요.) 사용자가 클릭해도 반응되지 않아야 하는데요..
문제는 이런 식의 상호관계가 점점 더 복잡해 질때... 보통 GUI 에서 어떻게 이런 문제를 다루는지 궁금합니다.
언뜻 생각해보게 되는게 state machine 인데요..
그러니까 각 상태별로 허락되는 메뉴와 아닌 메뉴를 구분해서 매 상태별로 메뉴를 업데이트 시키는 방법말이죠..
근데.. 이게 제게는 전혀 마음에 들지 않는 방법입니다.
너무 구식같아요..
좀 더 효율적이면서,
새로운 기능을 넣거나 뺄때에도 쉬운....
이런 잘 알려진 방법이 혹시 있는지요??
Forums:


아무도 안계신가요?
아무도 안계신가요?
질문을 좀 더 쉽게 고쳤습니다. 좋은 아이디어
질문을 좀 더 쉽게 고쳤습니다. 좋은 아이디어 있으시면 부탁드립니다~
의사결정트리?
의사결정트리?
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
데이터 마이닝에서 쓰이는 의사결정트리랑 이 문제랑 어떻게 연결이 되나요??
데이터 마이닝에서 쓰이는 의사결정트리랑 이 문제랑 어떻게 연결이 되나요??
잘 이해가 안되네요..
저도 모릅니다. 의사결정트리가 컴퓨터 시대 이전부터
저도 모릅니다.
의사결정트리가 컴퓨터 시대 이전부터 쓰이던 거 아닌가요?
제가 생각한 건 트리마다 확률이 쓰여있던 그래프입니다.
무슨 컨설팅 회사에서 나온 책에서 봤어요.
저도 잘 몰라서 물음표를 붙였습니다.
그리고 오토마타를 배운적이 없지만 오토마타는 이것과 무관한 건가요?
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
Case가 정확히 일치하는 경우는 없을 것 같긴
Case가 정확히 일치하는 경우는 없을 것 같긴 한데, 이런 방법은 어떨지?
각각의 메뉴항목에 그룹값(같은 그룹값을 가지는 메뉴는 같이 enable/disabled 된다고 가정하면)을 부여하고
메뉴실행중 SetMenuStatus(선택메뉴항목.그룹값, false); 메뉴실행후 SetMenuStatus(선택메뉴항목.그룹값, true); void SetMenuStatus(int group, bool bEnabled) { 메뉴항목 루프... { if (메뉴항목.그룹값 == group) 메뉴항목.enabled = bEnabled; } } <endcode>Signature :) - "여유를 갖고 행동하되 게을러지지 말자"
언뜻 HSM(hierarchical state
언뜻 HSM(hierarchical state machine)이 떠오르네요.
State machine이 커질 수록 복잡성이 급격히 높아지는 데 HSM은 "state nesting"이란 개념으로 복잡성을 상당히 줄여줄 수 있습니다.
State machine을 사용할 거라면 HSM을 고려해보세요.
단점은 이해하고 적용하는데 상당한 시간과 노력이 필요합니다.
http://www.accu-usa.org/Slides/samek0311.pdf
공부해봐야겠네요.. 답글 달아주셔서 감사합니다.
공부해봐야겠네요.. 답글 달아주셔서 감사합니다.
일단 state machine 을 벗어날 아이디어는 없는것 같네요...
Observer Pattern 류의 뭔가 좀 다른 아이디어는 없을까 했는데 말이죠..
아무튼 일단 공부해보겠습니다. 감사합니다.
생각만큼 그렇게 복잡하지는 않습니다. 메뉴는 GUI
생각만큼 그렇게 복잡하지는 않습니다. 메뉴는 GUI Element이기 때문에
화면상에 보이는 메뉴가 있고 보이지 않는 메뉴 (필요할 때 나타나는, 예를 들어 파일(F) 등) 가
있습니다.
화면상에 보이는 메뉴 (툴바 아이콘등..) 같은 경우에는
보통 관찰하고자 하는 상태변수에 (예를 들어 문서가 수정 되었는가 등)
따른 callback 이나 observer 형식으로 등록되어 관찰하고 있는
값이 변할 때 같이 변하도록 해줄 수 있습니다.
같은 그룹으로 묶여진 툴바 전체를 enable/disable할 수도 있겠지요.
눈에 보이지 않는 메뉴, 즉, 맨 위의 파일(F), 편집(E) 와 같은 메뉴를
눌렀을 때 아래에 나타나는 메뉴나, 필요한 경우 마우스 오른쪽버튼을 눌러서
나타나는 메뉴등의 경우에는, 메뉴가 화면에 display 되기 바로 전에
그 시점의 필요한 정보들을 가지고 해당메뉴의 상태를 설정한 뒤
사용자에게 보이도록 합니다. 따로 메뉴의 state등을 유지 관리해야할
필요는 없어보입니다.
현재 열려있는 브라우져 탭의 리스트가 메뉴에 나타나는 것도 위와 같이
화면에 보이기 바로 전에 그목록을 메뉴에 추가시켜서 보여주는 것입니다.