Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Keeping UDS_ALIGNRIGHT positioning for an updown control after moving the buddy window

Keeping UDS_ALIGNRIGHT positioning for an updown control after moving the buddy window

Scheduled Pinned Locked Moved C / C++ / MFC
wpfquestion
4 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Alexander Kindel
    wrote on last edited by
    #1

    In a winAPI project, I am generating dialog templates at compile time, but not setting the positions and sizes of the controls until runtime because they depend on the font, which I set to whatever the user has set as their lfMessageFont at runtime. One of the dialogs has an up-down control with a static control set as its buddy window. For the sake of consistency, I would like the up-down control to be positioned and sized according to the standards of the UDS_ALIGNRIGHT style. However, it seems that setting that style only suffices to position the up-down control according to the position and size of the buddy window as specified in the dialog template, and when I resize the buddy window when handling the dialog's WM_INITDIALOG message, the up-down control doesn't change with it. Is there a way to manually invoke the UDS_ALIGNRIGHT code again at this point? Or do I need to switch to generating the entire dialog template at runtime if I want to keep the effects of that style?

    L 1 Reply Last reply
    0
    • A Alexander Kindel

      In a winAPI project, I am generating dialog templates at compile time, but not setting the positions and sizes of the controls until runtime because they depend on the font, which I set to whatever the user has set as their lfMessageFont at runtime. One of the dialogs has an up-down control with a static control set as its buddy window. For the sake of consistency, I would like the up-down control to be positioned and sized according to the standards of the UDS_ALIGNRIGHT style. However, it seems that setting that style only suffices to position the up-down control according to the position and size of the buddy window as specified in the dialog template, and when I resize the buddy window when handling the dialog's WM_INITDIALOG message, the up-down control doesn't change with it. Is there a way to manually invoke the UDS_ALIGNRIGHT code again at this point? Or do I need to switch to generating the entire dialog template at runtime if I want to keep the effects of that style?

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      If you are adjusting size and position at run time, then you need to re-measure each control according to the new values that affect it. You also need to check any option settings on each control that may affect the layout. In your case the setting for UDS_ALIGNRIGHT will affect the control it is set on (the up/down) and the buddy window. See Up-Down Control Styles (CommCtrl.h) - Win32 apps | Microsoft Docs[^] for further information. [edit] You could load the resource dialog into memory and change the font details at runtime, and then invoke the dialog from the memory template. I am not 100% sure if that will work but a quick test should confirm it. [/edit]

      A 1 Reply Last reply
      0
      • L Lost User

        If you are adjusting size and position at run time, then you need to re-measure each control according to the new values that affect it. You also need to check any option settings on each control that may affect the layout. In your case the setting for UDS_ALIGNRIGHT will affect the control it is set on (the up/down) and the buddy window. See Up-Down Control Styles (CommCtrl.h) - Win32 apps | Microsoft Docs[^] for further information. [edit] You could load the resource dialog into memory and change the font details at runtime, and then invoke the dialog from the memory template. I am not 100% sure if that will work but a quick test should confirm it. [/edit]

        A Offline
        A Offline
        Alexander Kindel
        wrote on last edited by
        #3

        Inserting the font details into the template would save me having to send WM_SETFONT to every control in the dialog that has text while handling WM_INITDIALOG, as I do now, but I don't see what difference it would make in positioning the controls. One of the tools I use to determine the layout is Button_GetIdealSize, which I Can't call until I have an HWND for each control in question. As far as I can tell, that means I can't do it until I've instantiated an instance of the dialog. I guess I could instantiate an instance at startup, position and size the controls, alter the template to reflect the siz and position values this yields, then destroy the dialog. That way, each time an instance of the dialog is instantiated from then on, the layout will already be correct from the start. It seems like a rather tortured usage of the API, though. I'm not sure what you mean by remeasuring each control. Out of context, I'd have guessed that would mean calling GetWindowRect on each control, but I believe I know what values that would return a priori; it should zero out the struct if I do it before reformatting the control, reflecting the zeroed-out dialog template, and if I do it after reformatting, it should return the values I just specified. I'm similarly confused about what it means to check the control's option settings.

        L 1 Reply Last reply
        0
        • A Alexander Kindel

          Inserting the font details into the template would save me having to send WM_SETFONT to every control in the dialog that has text while handling WM_INITDIALOG, as I do now, but I don't see what difference it would make in positioning the controls. One of the tools I use to determine the layout is Button_GetIdealSize, which I Can't call until I have an HWND for each control in question. As far as I can tell, that means I can't do it until I've instantiated an instance of the dialog. I guess I could instantiate an instance at startup, position and size the controls, alter the template to reflect the siz and position values this yields, then destroy the dialog. That way, each time an instance of the dialog is instantiated from then on, the layout will already be correct from the start. It seems like a rather tortured usage of the API, though. I'm not sure what you mean by remeasuring each control. Out of context, I'd have guessed that would mean calling GetWindowRect on each control, but I believe I know what values that would return a priori; it should zero out the struct if I do it before reformatting the control, reflecting the zeroed-out dialog template, and if I do it after reformatting, it should return the values I just specified. I'm similarly confused about what it means to check the control's option settings.

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          All that is necessary is to load the dialog resource into memory and change the font size and name in the dialog template. This would involve copying it from the loaded resource to a new memory location to allow for changes in the number of characters in the font name. The sizes of individual controls should not need any changes, as the Windows library handles converting dialog units to pixels. See LoadResource function (libloaderapi.h) - Win32 apps | Microsoft Docs[^] and Dialog Box Structures - Win32 apps | Microsoft Docs[^] for more information.

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups