0

According to Microsoft's docs, the way to set custom Window data is to pass it through the lpParam argument of CreateWindowEx, retrieve it within the window procedure on WM_CREATE, and then set it using SetWindowLongPtr. I was wondering why you'd do that, instead of just setting it after calling CreateWindowEx, when you already have the window handle. Thanks for any guidance, and sorry if this is a basic question.

  • 1
    Lots of possible reasons, there is an entire api dedicated to hanging data off a window handle (Get/SetProp()). It mattered a lot back in the early days of Windows when per-process memory isolation did not exist yet. No matter today, but it still commonly gets used to associate an object pointer with a window, storing *this* for a C++ wrapper class. – Hans Passant May 20 '20 at 22:50
  • 3
    because before `CreateWindowEx` return control - your window already receive many messages, where you can need have pointer to your data. because this need do this on `WM_NCCREATE` (not on `WM_CREATE`) really by (windows design bug ?) even `WM_NCCREATE` not first message - `WM_GETMINMAXINFO` can be send before it. and here you have no data, if not use more complex solution. – RbMm May 20 '20 at 23:09
  • Ah, yes. I didn't think about that. Thank you very much. –  May 20 '20 at 23:15
  • @rbm That's not a Windows design bug. The bug is *your* expectation that the system were to operate in a way *you* want it to. You know how to write an implementation that doesn't rely on this undue assumption of message ordering. – IInspectable May 21 '20 at 05:43
  • @IInspectable - not agree. sense of `WM_NCCREATE` be the first message sent to window. and the `WM_NCDESTROY` the last. this need for correct assign/release data with window. need by design well known the first and the last message to do initialize/cleanup on it. and i think is wrong that `WM_GETMINMAXINFO` is sent before `WM_NCCREATE`. can you explain why ? why this is not bug ? you think we not need the well known first and last message ? – RbMm May 21 '20 at 06:47
  • @rbm Exactly. We do not need to know. If you need to allocate and release resources attached to the lifetime of a window, a CBT hook - for example - provides reliable lifetime callbacks that are immune to message ordering. The real issue is that you want to impose *your* design onto the system, and then turn around to call the system flawed, because it doesn't fit your proposed solution. Don't look any further, the bug is in *your* design. – IInspectable May 21 '20 at 11:39
  • @IInspectable - no, exist sense have well known/documented first and last message to window. and CBT hook not need anyway. if once somebody write this in mfc code this don`t mean that this need. more CBT hook - not receiver all windows messages, but some. and not documented that it called before first message received by windows. but how i say - reliable in current implementation way - save pointer to data say inside tls and use it on first (any) windowproc call. but you still can not understand that for this not need any CBT – RbMm May 21 '20 at 11:46
  • @rbm To summarize: You realize that a solution based on (undocumented) ordering of messages is not sufficient, and then move on to claim, that a different solution weren't required. Are you able to resolve this without your statements contradicting each other? – IInspectable May 21 '20 at 12:06
  • @IInspectable - i say that i think than will be correct have well known first and last message received by window. not normal situation when we need set additional callback like CBT for got data, which we can receive just inside window proc callback. i sure that this is design bug. also i say that use CBT not only single solution, can use and other ways. – RbMm May 21 '20 at 12:11
  • @IInspectable To summarize: You think that is good design not have documented message which called always first and have user pointer (passed to createwindow), but requiring setup **additional** callback which will be documented called first with this pointer – RbMm May 21 '20 at 12:21
  • @rbm *"You think that is good design not have documented message which called always first"* - No. I'm saying that it is inconsiderate to be well aware, that there is no such documentation, and insist on promoting a design that relies on such documentation. *"also i say that use CBT not only single solution, can use and other ways."* - Sure. Use [WinEvents](https://learn.microsoft.com/en-us/windows/win32/winauto/winevents-infrastructure) if you so desire. – IInspectable May 21 '20 at 12:55
  • @IInspectable use `SetWinEventHook` here exactly no sense use because in it callback we not receive back pointer to our data at all. so no sense. in CBT callback we receive this pointer back inside `CBT_CREATEWND` (but mfc not use anyway, what is strange design for me) but possible and another solution - save this pointer in tls slot and take it back on first windowproc call. but the best solution will be, if `WM_NCCREATE` always called first and not need hooks and etc. i and say that think- this is ms design bug send `WM_GETMINMAXINFO` before `WM_NCCREATE` – RbMm May 21 '20 at 13:09

0 Answers0