Microsoft MVP성태의 닷넷 이야기
Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법 [링크 복사], [링크+제목 복사],
조회: 11373
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 21개 있습니다.)
Windows: 226. Win32 C/C++ - Dialog에서 값을 반환하는 방법
; https://www.sysnet.pe.kr/2/0/13284

Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법
; https://www.sysnet.pe.kr/2/0/13285

Windows: 228. Win32 - 리소스에 포함된 대화창 Template의 2진 코드 해석 방법
; https://www.sysnet.pe.kr/2/0/13286

Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법
; https://www.sysnet.pe.kr/2/0/13287

Windows: 230. Win32 - 대화창의 DLU 단위를 pixel로 변경하는 방법
; https://www.sysnet.pe.kr/2/0/13288

Windows: 231. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 자식 윈도우를 생성하는 방법
; https://www.sysnet.pe.kr/2/0/13289

Windows: 232. C/C++ - 일반 창에도 사용 가능한 IsDialogMessage
; https://www.sysnet.pe.kr/2/0/13292

Windows: 233.  Win32 - modeless 대화창을 modal처럼 동작하게 만드는 방법
; https://www.sysnet.pe.kr/2/0/13295

Windows: 234. IsDialogMessage와 협업하는 WM_GETDLGCODE Win32 메시지
; https://www.sysnet.pe.kr/2/0/13296

Windows: 235. Win32 - Code Modal과 UI Modal
; https://www.sysnet.pe.kr/2/0/13297

Windows: 237. Win32 - 모든 메시지 루프를 탈출하는 WM_QUIT 메시지
; https://www.sysnet.pe.kr/2/0/13299

Windows: 238. Win32 - Modal UI 창에 올바른 Owner(HWND)를 설정해야 하는 이유
; https://www.sysnet.pe.kr/2/0/13300

Windows: 242. Win32 - 시간 만료를 갖는 MessageBox 대화창 구현 (쉬운 버전)
; https://www.sysnet.pe.kr/2/0/13305

Windows: 243. Win32 - 윈도우(cbWndExtra) 및 윈도우 클래스(cbClsExtra) 저장소 사용 방법
; https://www.sysnet.pe.kr/2/0/13306

Windows: 244. Win32 - 시간 만료를 갖는 MessageBox 대화창 구현 (개선된 버전)
; https://www.sysnet.pe.kr/2/0/13312

Windows: 245. Win32 - 시간 만료를 갖는 컨텍스트 메뉴와 윈도우 메시지의 영역별 정의
; https://www.sysnet.pe.kr/2/0/13315

Windows: 246. Win32 C/C++ - 직접 띄운 대화창 템플릿을 위한 Modal 메시지 루프 생성
; https://www.sysnet.pe.kr/2/0/13329

Windows: 247. Win32 C/C++ - CS_GLOBALCLASS 설명
; https://www.sysnet.pe.kr/2/0/13330

Windows: 248. Win32 C/C++ - 대화창을 위한 메시지 루프 사용자 정의
; https://www.sysnet.pe.kr/2/0/13332

Windows: 249. Win32 C/C++ - 대화창 템플릿을 런타임에 코딩해서 사용
; https://www.sysnet.pe.kr/2/0/13333

Windows: 250. Win32 C/C++ - Modal 메시지 루프 내에서 SetWindowsHookEx를 이용한 Thread 메시지 처리 방법
; https://www.sysnet.pe.kr/2/0/13334




Win32 C/C++ - Dialog Procedure를 재정의하는 방법

지난 글에서,

Win32 C/C++ - Dialog에서 값을 반환하는 방법
; https://www.sysnet.pe.kr/2/0/13284

소개한 About과 같은 함수를 Dialog Procedure라고 합니다. 이와 유사한 이름 및 구조의 Procedure가 또 있는데요, 바로 Window Procedure라고 불리는 함수입니다. (이전 글에서 WndProc이라는 이름으로 기본 함수 코드를 실었습니다.)

그런데 그 둘 간의 차이점이 하나 있습니다. 우선 Dialog Procedure는 직접 Window 메시지를 수신하지는 않고 DefDlgProc이 대신 수신한 다음 그것의 내부에서 Dialog Procedure가 불린다는 점입니다.

반면 Window Procedure는 직접 메시지를 수신한다는 차이점이 있습니다. 이로 인해 "기본 동작"을 수행하는 코드의 위치도 다릅니다. Dialog Procedure의 경우에는 FALSE를 반환하면 DefDlgProc이 기본 동작을 담당하는 반면, Window Procedure는 내부에서 직접 DefWindowProc을 호출해 기본 동작을 맡깁니다.

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    //...[생략]...
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

그러니까, Dialog Procedure와 Window Procedure는 그 이름 규칙에서 서로 상반된 호출 관계를 갖고 있는 것입니다.

Window Procedure => DefWindowProc
DefDlgProc => Dialog Procedure




그나저나, 사람들도 참 다양합니다. ^^ 어떤 개발자들은 Dialog Procedure도 Window Procedure와 같은 식의 구조로 코딩하고 싶은 경우가 있다고 합니다. 즉, 지난번에 설명한 About 함수와 같은 형식이 아닌, 다음과 같이 내부에서 기본 동작이 필요한 경우 DefDlgProc을 호출하는 형식으로 처리하고 싶다는 것입니다.

LRESULT CALLBACK SampleWLDialogProc(HWND hdlg, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uiMsg) {
    case WM_INITDIALOG:
        break;
    case WM_COMMAND:
        switch ((wParam)) {
        case IDOK:
        case IDCANCEL:
            EndDialog(hdlg, 1);
            break;
        }
        break;
    case WM_SETCURSOR: /*
How can I trigger a recalc of the mouse cursor after I changed some of my internal application state?
; https://devblogs.microsoft.com/oldnewthing/20220921-00/?p=107203

How can I trigger a recalc of the mouse cursor after I changed some of my internal application state?, follow-up
; https://devblogs.microsoft.com/oldnewthing/20230525-00/?p=108247
                       */
        if (LOWORD(lParam) == HTCAPTION) {
            SetCursor(LoadCursor(NULL, IDC_SIZEALL));
            return TRUE;
        }
        break;
    }
    return DefDlgProc(hdlg, uiMsg, wParam, lParam);
}

이렇게 하는 첫 번째 방법을 다음의 글에서 설명하고 있습니다.

A different type of dialog procedure
; https://devblogs.microsoft.com/oldnewthing/20031112-00/?p=41863

1992년부터 마이크로소프트가 공개한 기법이라고 하는데 대략 다음과 같은 흐름을 같습니다.

Message delivered
-> DefDlgProc
   -> your dialog procedure
      decide what to do
      want to do the default action
      -> DefDlgProc
         -> your dialog procedure
            detect recursion
         <- return FALSE
         DefDlgProc sees FALSE
         performs default behavior
      <- returns result of default behavior
      you do other stuff (perhaps modify
      default behavior after it occurred)
      set DWLP_MSGRESULT to desired result
   <- return TRUE
   retrieve DWLP_MSGRESULT
<- return it as message result

보시면 DefDlgProc이 재귀적으로 호출되는 흐름을 갖는 데다, 그것을 막기 위해 플래그 변수를 하나 두는 방식이라 별로 마음에 들지 않습니다. ^^

그보다는, 차라리 2번째 방법이 더 깔끔해 마음에 듭니다.

Another different type of dialog procedure
; https://devblogs.microsoft.com/oldnewthing/20031113-00/?p=41843

이번 글에서는 위의 방법을 정리해 보겠습니다. ^^

그러니까 사실, DialogBox도 결국 내부에서는 CreateWindowEx를 이용해 윈도우를 띄우는 것에 불과합니다. 그렇다면 그와 연관된 "Window Class"가 있을 텐데요, 이것을 spy++와 같은 도구를 이용해 확인할 수 있습니다.

redef_dialog_proc_1.png

그렇습니다. #32770 유형의 윈도우는 DefDlgProc을 Window Procedure로 지정한, 어찌 보면 사용자 정의 윈도우였던 것입니다.

자, 그럼 게임 끝이군요. 따라서 이제 흐름을 다음과 같이 정리할 수 있습니다.

Message delivered
-> (기존의 DefDlgProc을 대체한) WLWndProc
   -> 우리가 제공하는 (Window Procedure처럼 코딩할) Dialog Procedure 
      decide what to do
      want to do the default action
      -> (기본 처리를 수행하는) DefDlgProc
         -> (DefDlgProc이 기존에 호출했던 Dialog Procedure를 대신할) dummy dialog procedure
         <- always returns FALSE
         DefDlgProc does default action
      <- returns result of default behavior
      you do other stuff (perhaps modify
      default behavior after it occurred)
   <- returns result
<- returns result

하나씩 해결해 볼까요? ^^ 당연히 기존의 DefDlgProc 역할을 수행할 Window Procedure를 새롭게 지정한 윈도우 클래스를 하나 만들어야 합니다.

LRESULT CALLBACK WLWndProc(HWND hdlg, UINT uiMsg, WPARAM wParam, LPARAM lParam);

BOOL InitApp(HINSTANCE hInstance)
{
    WNDCLASS wc;
    wc.style = CS_DBLCLKS | CS_SAVEBITS | CS_BYTEALIGNWINDOW;
    wc.lpfnWndProc = WLWndProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = DLGWINDOWEXTRA + sizeof(WLDLGPROC);
    wc.hInstance = hInstance;
    wc.hIcon = NULL;
    wc.hCursor = LoadCursor(NULL, IDC_ARROW);
    wc.hbrBackground = NULL;
    wc.lpszMenuName = NULL;
    wc.lpszClassName = TEXT("WLDialog");
    if (!RegisterClass(&wc)) return FALSE;
    return TRUE;
}

cbWndExtra에 대화창을 위한 기본 부가 영역의 크기를 담고 있는 DLGWINDOWEXTRA, 즉 30바이트와 사용자가 나중에 전달할 (Window Procedure처럼 코딩할) Dialog Procedure 주소를 포함한 sizeof(WLDLGPROC) 바이트를 추가 지정합니다.

위의 코드에서 lpszClassName을 통해 윈도우 클래스 이름을 "WLDialog"로 했는데, 따라서 RC 파일에 있는 대화창에 (기본값 #32770이 적용되지 않도록) "WLDialog"을 지정해 줍니다.

IDD_ABOUTBOX DIALOGEX 0, 0, 170, 62
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "About Project1"
CLASS "WLDialog"
FONT 8, "MS Shell Dlg"
BEGIN
    ICON            IDR_MAINFRAME,IDC_STATIC,14,14,21,20
    LTEXT           "Project1, Version 1.0",IDC_STATIC,42,14,114,8,SS_NOPREFIX
    LTEXT           "Copyright (c) 2023",IDC_STATIC,42,26,114,8
    DEFPUSHBUTTON   "OK",IDOK,113,41,50,14,WS_GROUP
END

그리고 이렇게 만들어진 윈도우 클래스의 Window Procedure는 우리가 만든 Dialog Procedure를 호출하는 코드를 추가합니다.

LRESULT CALLBACK WLWndProc(HWND hdlg, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    if (uiMsg == WM_INITDIALOG) {
        WLDIALOGINFO* pwldi = (WLDIALOGINFO*)lParam;
        SetWindowLongPtr(hdlg, DLGWINDOWEXTRA, (LONG_PTR)pwldi->wldp);
        lParam = pwldi->lParam;
    }
    
    WLDLGPROC wldp = (WLDLGPROC)GetWindowLongPtr(hdlg, DLGWINDOWEXTRA);
    
    if (wldp) {
        return wldp(hdlg, uiMsg, wParam, lParam);
    }
    else {
        return DefDlgProc(hdlg, uiMsg, wParam, lParam);
    }
}

아쉽게도 DLGWINDOWEXTRA 공간에 전달해야 할 WLDIALOGINFO 구조체 때문에 기존 DialogBox 등의 API를 호출하는 것은 불가능합니다. 즉, 새로운 호출 API를 다음과 같이 만들어야 하는데,

INT_PTR CALLBACK DummyDlgProc(HWND hdlg, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    return FALSE;
}

INT_PTR WLDialogBoxParam(HINSTANCE hinst, LPCTSTR pszTemplate, HWND hwndParent, WLDLGPROC wldp, LPARAM lParam)
{
    WLDIALOGINFO wldi = { wldp, lParam };
    return DialogBoxParam(hinst, pszTemplate, hwndParent, DummyDlgProc, (LPARAM)&wldi);
}

보시면 기존의 DialogBoxParam에 DummyDlgProc을 전달해 내부의 DefDlgProc이 호출할 것도 제공함과 동시에 LPARAM 인자로 우리가 만든 WLDLGPROC wldp를 WLWndProc에서 인식할 수 있도록 WLDIALOGINFO로 감싸 전달하고 있습니다.

끝입니다. ^^ 이제 기존의 About 창을 다음과 같이 호출하면 됩니다.

WLDialogBoxParam(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, SampleWLDialogProc, 0);

그럼, 대화창의 윈도우 클래스가 바뀌고,

redef_dialog_proc_2.png

Window Procedure와 유사한 코딩 방식으로 만든 SampleWLDialogProc이 정상적으로 수행되는 것을 확인할 수 있습니다.




위에서 GetWindowLongPtr/SetWindowLongPtr을 통한 방법은 DefDlgProc이 했던 것과 유사합니다. 지난 글에 DefDlgProc의 가상 코드를 설명했는데요,

LRESULT CALLBACK DefDlgProc(
    HWND hdlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    DLGPROC dp = (DLGPROC)GetWindowLongPtr(hdlg, DWLP_DLGPROC);
    SetWindowLongPtr(hdlg, DWLP_MSGRESULT, 0);
    BOOL_PTR fResult = dp(hdlg, uMsg, wParam, lParam);
    if (fResult) return GetWindowLongPtr(hdlg, DWLP_MSGRESULT);
    else ... do default behavior ...
}

보시면 유사하게 처리한 것을 볼 수 있습니다. 결국, DummyDlgProc을 우리도 마찬가지로 구해서 호출(할 필요는 없지만)하는 것이 가능합니다.

LRESULT CALLBACK WLWndProc(HWND hdlg, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    if (uiMsg == WM_INITDIALOG) {
        WLDIALOGINFO* pwldi = (WLDIALOGINFO*)lParam;
        SetWindowLongPtr(hdlg, DLGWINDOWEXTRA, (LONG_PTR)pwldi->wldp);
        lParam = pwldi->lParam;
    }

    WLDLGPROC dummy = (WLDLGPROC)GetWindowLongPtr(hdlg, DWLP_DLGPROC);
    if (dummy)
    {
        dummy(hdlg, uiMsg, wParam, lParam);
    }
    
    WLDLGPROC wldp = (WLDLGPROC)GetWindowLongPtr(hdlg, DLGWINDOWEXTRA);
    
    if (wldp) {
        return wldp(hdlg, uiMsg, wParam, lParam);
    }
    else {
        return DefDlgProc(hdlg, uiMsg, wParam, lParam);
    }
}

많이 귀찮겠지만, ^^ DefDlgProc을 아예 우리가 만들어 버리는 것도 가능한 것입니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 5/31/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2025-04-25 08시30분
What is the process by which the cursor gets set?
; https://devblogs.microsoft.com/oldnewthing/20061121-15/?p=28943

WM_SETCURSOR 메시지는 커서가 위치한 윈도우에 전송되고, 그 윈도우에서는 WM_SETCURSOR 메시지에서 return TRUE를 하는 것으로 커서를 결정할 수 있음. 만약 스스로 처리하지 않게 되면 DefWindowProc은 그것의 부모 윈도우에게 메시지를 전달, 따라서 조상 윈도우 중에 WM_SETCURSOR를 처리한다면 그에 따라 커서를 결정, 만약 조상 윈도우에서도 WM_SETCURSOR를 처리하지 않는다면 (RegisterClass로 등록한) Window Class에 설정했던 hCursor로 처리

재미있는 건, DefWindowProc에서 Window Class의 커서를 설정하긴 하지만 return FALSE를 하므로 결국 최초 커서 밑에 있던 윈도우의 DefWindowProc에서는 그 윈도우가 속한 Window Class의 hCursor를 로드하게 됨.

아래의 예는 커서 밑에 3개의 윈도우가 있다고 가정 (A: top-level window, B: A의 자식 윈도우, C, B의 자식 윈도우)

SendMessage(hwndC, WM_SETCURSOR, ...)
 C's window procedure does nothing special
 DefWindowProc(hwndC, WM_SETCURSOR, ...)
  DefWindowProc forwards to parent:
   SendMessage(hwndB, WM_SETCURSOR, ...)
   B's window procedure does nothing special
   DefWindowProc(hwndB, WM_SETCURSOR, ...)
    DefWindowProc forwards to parent:
     SendMessage(hwndA, WM_SETCURSOR, ...)
     A's window procedure does nothing special
      DefWindowProc(hwndA) cannot forward to parent (no parent)
      DefWindowProc(hwndA) sets the cursor to C's class cursor
      DefWindowProc(hwndA) returns FALSE
     A's window procedure returns FALSE
    SendMessage(hwndA, WM_SETCURSOR, ...) returns FALSE
    DefWindowProc(hwndB) sets the cursor to C's class cursor
    DefWindowProc(hwndB) returns FALSE
   B's window procedure returns FALSE
  SendMessage(hwndB, WM_SETCURSOR, ...) returns FALSE
  DefWindowProc(hwndC) sets the cursor to C's class cursor
  DefWindowProc(hwndC) returns FALSE
 C's window procedure returns FALSE
SendMessage(hwndC, WM_SETCURSOR, ...) returns FALSE

이와 함께 일부 프로그램에서 커서 설정을 WM_MOUSEMOVE에서 하는데 이에 대해 문제가 없는지에 대한 답변이 나오는데요, 관련해서는 꼭 안 된다는 법칙은 없어도 그렇게 하는 경우 커서 깜빡임이 있을 것이라고 합니다. 즉, 윈도우 시스템은 매번 WM_SETCURSOR를 보낼 것이고, 그로 인해 (위의 절차에 따라) 커서가 바뀔 것이고, 그 와중에 WM_MOUSEMOVE에서 다시 커서를 설정하므로 깜빡임 현상이 나오는 것입니다.

깜빡임 현상을 도드라지게 하기 위해 다음과 같은 소스 코드로 테스트하면 된다고.

void
OnMouseMove(HWND hwnd, int x, int y, UINT keyFlags)
{
 Sleep(10); // just to make the flicker more noticeable
 SetCursor(LoadCursor(NULL, IDC_CROSS));
}
 // Add to WndProc
 HANDLE_MSG(hwnd, WM_MOUSEMOVE, OnMouseMove);
정성태
2025-04-25 08시52분
When I define a window class with no default cursor, what is the explanation for the cursors that appear in my client area?
; https://devblogs.microsoft.com/oldnewthing/20250424-00/?p=111114

Window Class의 hCursor 필드에 nullptr을 설정한 경우, 윈도우가 처음 나왔을 땐 모래 시계 커서가 되었다가, 윈도우 경계로 마우스를 이동하면 border 커서로 바뀌고는 이후 윈도우 영역으로 다시 돌아오면 그대로 border 커서가 유지됨.

왜냐하면, Window Class의 커서를 nullptr로 설정하게 되면 DefWindowProc에서 아무런 처리를 안 하는 것과 같기 때문. 당연히 윈도우 경계로 커서를 이동하면 그에 따라 border 커서로 바뀔 것이고, 그 상태에서 다시 윈도우 영역으로 와도 DefWindowProc에서 하는 일이 없으므로 기존의 커서가 그대로 유지되는 현상이 발생함.

일반적으로는, Window Class의 hCursor를 설정하지 않는다면 반드시 Window Procedure의 WM_SETCURSOR에서 명시적으로 커서를 설정하는 코드를 수반해야 함.
정성태

1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...
NoWriterDateCnt.TitleFile(s)
13566정성태2/27/20249526오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20248622닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/202410138Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20249629디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20249332오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/202410132닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/202410182디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/202410990오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/202410167닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20249045Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20249423Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20249631닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20249054VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20248605닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20248716닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20249807닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/202410249Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/202411218개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/202410780개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/202410442개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/202410136Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20249654닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20249320오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20249749Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20248827오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20249577VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...