# glfwPollEvents automatically set the close flag which causes GLFW to close the window

**URL:** <https://discourse.glfw.org/t/glfwpollevents-automatically-set-the-close-flag-which-causes-glfw-to-close-the-window/1461>\
**Category:** support\
**Created:** [December 21, 2019, 4:30pm UTC](https://discourse.glfw.org/t/glfwpollevents-automatically-set-the-close-flag-which-causes-glfw-to-close-the-window/1461 "2019-12-21T16:30:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![deadshot465](https://avatars.discourse-cdn.com/v4/letter/d/a88e4f/32.png) [@deadshot465](https://discourse.glfw.org/u/deadshot465)\
**Post date:** [December 21, 2019, 4:30pm UTC](https://discourse.glfw.org/t/glfwpollevents-automatically-set-the-close-flag-which-causes-glfw-to-close-the-window/1461/1 "2019-12-21T16:30:23Z")

</div>

Does anyone know under what circumstances will glfwPollEvents() automatically set the close flag that causes GLFW to close the window?

For learning purpose, currently my program contains both DirectX11’s code (using Win32 API directly) and OpenGL’s code (using GLFW). The window creation and main loop for each API are in separate functions. When you select another API from the UI inside the program, it will cause the function to return to the main function, which will destroy the current window and release all resource (since they are local variables), and call another function to create a new window and a main loop. Switching from GLFW to Win32 has no problem at all, but when switching from Win32 to GLFW, despite that GLFW window can be created without any problem and error, the main loop will execute only once, then it will automatically close afterwards. Both glError() and glfwGetError() return no errors at all.

After debugging I found that glfwPollEvents() somehow sets the close flag, which causes glfwWindowShouldClose() to return true and end the main loop. If I comment out glfwPollEvents(), OpenGL will render without any problem, but of course there won’t be any event polling. I tried setting up WindowCloseCallback, and right after the program executes glfwPollEvents(), the callback is called, so clearly either glfwPollEvents() sets the close flag, or the flag is set elsewhere. The problem is KeyCallback is never called and I didn’t call glfwSetWindowShouldClose() anywhere in the code, so I don’t know why the close flag is set.

Does anyone know why this happened? Thanks.

---

<div class="post-metadata">

**Author:** ![dougbinks](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.glfw.org/dougbinks/32/39_2.png) [@dougbinks](https://discourse.glfw.org/u/dougbinks)\
**Post date:** [December 21, 2019, 4:56pm UTC](https://discourse.glfw.org/t/glfwpollevents-automatically-set-the-close-flag-which-causes-glfw-to-close-the-window/1461/2 "2019-12-21T16:56:27Z")

</div>

Hi @deadshot465 welcome to the GLFW forums!

The Windows implementation of GLFW sets the window close flag if WM\_QUIT is sent to the application or WM\_CLOSE is sent to a window are received. I suspect one of these is still in the message queue after you destroy the first window, and thus glfwPollEvents() picks this up and closes the window.

Since WM\_CLOSE is sent to a particular window handle, I’d guess that the message you’re getting is WM\_QUIT. If you’re able to set breakpoints in the code of the \_glfwInputWindowCloseRequest function you should be able to see what’s causing it to close.

If this is indeed the problem, clearing out the message queue completely prior to opening the new window might help.

---

<div class="post-metadata">

**Author:** ![deadshot465](https://avatars.discourse-cdn.com/v4/letter/d/a88e4f/32.png) [@deadshot465](https://discourse.glfw.org/u/deadshot465)\
**Post date:** [December 21, 2019, 5:36pm UTC](https://discourse.glfw.org/t/glfwpollevents-automatically-set-the-close-flag-which-causes-glfw-to-close-the-window/1461/3 "2019-12-21T17:36:08Z")

</div>

Thank you for the insight!  
Indeed, it was the WM\_QUIT message that was still lingering in the queue. After I used PeekMessage() to ensure that WM\_QUIT was removed before creating another window, everything worked.

Thank you again for the help 🙂