안녕하세요.
컨트롤 배치하면서 F5누르면서 실행해 보면서 작업하다 보면 멈추는 경우가 많습니다.
물론 조금 기다리면 대부분 해제되어 다시 컨트롤을 배치할 수 있는 상태로 돌아오긴 합니다만,
간혹 몇 초 이상 기다려야 하는 경우도 생기고 어쩔 때는 한참을 기다려야 하는 경우가 생기기도 합니다.
제 코드에 문제가 있는 것일까요? 설정의 문제일까요. 아니면 일반적으로 그런걸까요…
이에 대한 조언이나 경험 공유해 주시길 부탁드립니다. 그리고 wpf질문이 많은 것으로 보이는데, wpf는 xml기반이라는 것만 알고 있습니다. wpf는 디자이너가 좀 더 가벼운 편인지도 궁금합니다. 가볍다고 해도 wpf포팅하는게 쉬운 일은 아니겠지요…
첫번째로,
기준은 항상 상대적이기 때문에 원하시는 답변을 위해 좀 더 구체적인 정보가 필요합니다. 가령, 윈폼 디자이너가 무겁다고 느끼시는 샘플 코드를 공유해주셔도 괜찮고, .NET Framework에서는 빨랐던것 같은데 .NET Core로 넘어오면서, 혹은 Visual Studio 2017은 빨랐는데 2019로 넘어오면서 느려졌다는 등,
원하시는 답을 드리기 위해서는 정보가 더 필요해 보입니다.
두번째로,
일반적으로 Windows Forms 디자이너와 WPF 디자이너 들 중 무엇이 더 가벼운지에 대한 부분도 첫번째와 유사한 면이 있습니다.
저의 경험을 공유 해보자면, Windows Forms 디자이너 또는 WPF 디자이너 모두 무겁다고 느껴보지는 못했습니다. 물론, 컨트롤의 개수가 많아지면 Windows Forms 디자이너의 편집 기능이 많이 느려지는 경향은 있으나, 반대로 불필요하게 컨트롤을 많이 사용한게 아닌가 하는 접근으로 해결을 합니다.
WPF의 경우 제가 경험한 환경에서는 디자이너가 힘들어할 정도로 경험하지 못했습니다.
Winform의 디자이너가 멈출 정도로 느리다면 확장 프로그램이나 설정상 문제일 가능성이 큽니다. VM 같은곳에 윈도우를 깔고 VS만 설치한 뒤에 똑같은 소스를 테스트해보시면 알 수 있을거같네요.
참고로, WPF는 더 무겁니다.
답변 주셔서 감사합니다.
컨트롤 배치 변경시에 디자이너에서 F5로 실행시킨 후 디버깅 모드로 실행되던 윈도우를 종료시키면 20초 정도 딜레이가 있거든요. 전 그동안 vs 문제일 가능성이 더 많다고 생각했었거든요. 그런데, 말씀해 주신 것으로 보아 그렇지 않을 가능성이 많은 것 같네요. 우선은 제가 가능성이 있는 부분들에서 대해서 하나씩 테스트 한 후에 추가적인 궁금증이 생기면 상세한 정보과 함께 댓글을 남기도록 하겠습니다.
네. 이전 버전에서부터 설정을 export해서 사용했기 때문에 그럴 가능성도 많을 것 같습니다. 조언 주신대로 격리된 환경에서 설정부터 확인해 보도록 하겠습니다. 감사의 말씀을 전합니다. 
@ktkt 안녕하세요. 
Windows Forms, WPF 디자이너 모두 숙련도에 영향이 큰 것 같습니다.
그리고 디자이너 모드일 때에도 실제 보여지는 모든 객체의 생성자와 Laod 이벤트 등이 모두 실행되기 때문에 어떤 방식으로 개발 하는지에 따라 퍼포먼스에 차이가 날 수도 있지만 @dimohy 님 말씀처럼 어디까지나 상대적이기 때문이라는 것에 동의합니다.!!
답변 감사드립니다. 댓글들을 보니 제 코드를 분석해 가고 있는데요.
생성자는 영향이 있는 걸 전에 알고서 이 부분에 신경을 쓰고 있는데, 아직은 분석해야 할 부분이 더 있어 보입니다.
실제 멤버변수등도 생성자가 호출될 때 모두 생성이 되더라구요. 해서 프로젝트를 nullable로 하고 가능한 가볍게 만들어 보려고 방향을 잡고 있습니다.
Load이벤트도 호출되는지는 몰랐는데, 혹시 이 부분에 대한 분석방법은 어떻게 하는게 좋을까요?
개인적 경험으로는 vs에서 윈폼에 컨트롤을 많이 올릴 수 밖에 없는 상황에서 편집 작업 및 로딩시 느려져서 wpf로 재작업한 경험이 있습니다. wpf에 많은 컨트롤을 올렸을때 화면 로딩에 문제가 없었습니다. 작업이 다급한 상황이라 원인 분석은 못했었구요.
html 인라인 코딩에 익숙했었던지라 wpf xml기반 레이아웃이 작업하기 쉬웠습니다. 일단 원하는 비주얼작업이 간편했습니다.
답변 감사드립니다. 많이 올린다는 것은 대강 얼마나 될까요?
저도 폼이 좀 무겁긴 합니다. ㅎ
기본적으로 메인폼에 그리드와 버튼등이 30여개 있고, 탭컨트롤로 5개 정도 하위에 컨트롤이 있고,
서브폼이이 4개 정도 있는데 각각 스플리터, 탭컨트롤등에 추가되어 있으며
서브폼에는 기본적으로 그리드나 리스트컨트롤이 있고, 서브폼마다 30여개 정도의 컨트롤이 있습니다.
서브폼 중에 한곳에 webview2컨트롤이 있고요.
wpf로 포팅하는 것은 시간이 많이 걸리지 않을까 하여 망설여지네요…
@_jeonghwan 저도 WPF를 시작했을 때 비슷한 경험이었습니다.
Html과 유사한 느낌을 받아 좀 더 재미있게 시작했어요.
@ktkt 그리고 이 둘의 환경은 C#을 사용하는 것 외에 거의 모든 부분들과 개발 방식이 상당히 다르기 때문에 포팅을 하시는 것은 위험부담이 따를 것 같습니다. 그 전에 먼저 WPF 학습을 해보시는 것을 추천드립니다.
윈폼에서 wpf로 넘어가는 추천해 주실만한 학습 방법이 있을까요?
제가 MFC에서 윈폼으로 넘어오게 되었는데요, 당시에도 wpf가 있었는지는 모르겠는데, 윈폼이 더 비슷했거든요. mfc는 win32 api로 윈도우 프로그램을 만드는 것보다 클래스로 잘 래핑되어서 오히려 더 편하다고 느껴졌는데, wpf는 어떤 컨셉인지 궁금합니다.
@_jeonghwan wpf로 포팅하기엔 좀 부담스럽긴 한데 다음 프로젝트는 wpf로 해 보고 싶네요~
mfc에서 윈폼이야 거의 비슷하니 수정이 쉬웠을 거고요.
wpf는 차라리 웹에 더 가까운 형태입니다.
mfc랑 winform만 해 보신거면 wpf로 포팅은 추천할 수 없을것 같고요.
새 프로젝트가 있을 시 wpf로 해 보시는걸 추천 드립니다.
html처럼 마크업언어로 xml을 사용하고 자바스크립트 대신에 c#으로 코딩해서 구현한다고 봐도 무방할까요?
그럼 asp.net core처럼 mvc패턴이나 의존성 주입 같은 것도 지원해 주나요?
여기 커뮤니티 에서 WPF로만 검색해도 엄청 많은글이 나오고
또 MSDN도 잘 되어 있으니 그걸로 일단 공부를 하시면서 이해가 안되는것만
콕콕 집어서 질문글을 올리시는게 나을것 같네요.
답변 감사드립니다. 자료조사 해 보겠습니다.
많은 컨트롤을 실행시 winform이 느린 이유가 이것 때문인것 같네요~~
다른 내용을 찾아보다가 생각나서 링크 올립니다.
다른 회원님의 사이트에 내용이 잘 나와있습니다.
https://www.sysnet.pe.kr/2/0/12770
wpf가 더 가벼운 이유가 다 있었군요. 좋은 정보 감사드립니다.
뒷북 댓글 올려서 죄송합니다…
내부 로직은 다 무시하고 컨트롤의 개수로 부하도를 따지면 윈폼에서 부하가 훨씬 큽니다.
WPF는 확실히 부하가 적구요.
(저같은 경우는 이런 단점을 극복해서라도 윈폼으로 작업하는 것을 선호하는 편입니다.)
윈폼에서 디자인 영역에서 부하를 가장 많이 받는게 Panel, TableLayoutPanel, TabControl 처럼 Container 역할을 하는 컨트롤입니다.
구글 검색해보시면 간단하게 DoubleBuffering을 구현하는 소스가 많이 나와있으니,
개인적으로는 이런걸 참조하셔서 기본 컨트롤을 상속받은 컨트롤을 생성해서 쓰시는 것을 추천드립니다.
글쓰신 분께서는 이미 해결을 다 하셨겠지만 혹시나 다른 분이 나중에 이 글을 보셨을 때 참고하시라고 뒷북 댓글 한번 달아봤습니다.
이해해주세요
아니요. 글 환영하고 감사합니다. 질문 컨텐츠도 유익한 이유가 유사한 문제를 겪고 있는 다른 분이 댓글을 따라 가며 본인에 유익한 정보를 얻어갈 수 있기 때문입니다.
뒷북 댓글을 또 늦게 보았네요.ㅎㅎ
제가 그 무거은 것들을 모두 사용하고 있었네요.
사실 문제를 제대로 해결하지는 못하고 있었는데요. 더블버퍼링이 가볍다면 기본으로 추가해 줬으면 좋았을텐데 아쉬움이 남네요. 아무튼 여유가 될 때 컨테이너 교체를 해 봐야겠네요.
감사드립니다.