Moving Date Time Picker Control

Also is the width you supply wide enough?

I'm not certain of anything<g>

I have tried various variations for both first and last parameters. I have been playing with wider widths. See the code snippet and screenshot for two experiments.

Thanks

        GetDlgItem(IDC_COMPDATEFROM)->SetWindowPos(&wndTop,DLGX(230),DLGY(208),DLGX(63),DLGY(14),SWP_DRAWFRAME | SWP_SHOWWINDOW | SWP_NOCOPYBITS    ) ;
        GetDlgItem(IDC_COMPDATETO)->SetWindowPos(NULL,DLGX(310),DLGY(208),DLGX(58),DLGY(14),NULL) ;
                                              

1:
2:

Is there some other control that overlaps them?

Assume the check box displayed has the following ID for the following code

GetDlgItem(IDC_COMPDATEFROM)->SetWindowPos(GetDlgItem(IDC_CHECK1),DLGX(230),DLGY(208),DLGX(63),DLGY(14), SWP_SHOWWINDOW);

Does that help?

Thanks Andy, but your suggestion had no effect.

It is a very busy form with many options: controls do overlap but those that do in this case are hidden.

I went through this exercise to remove confusion when modifying the form: I think it is time to place them using the IDE and tolerate the mess that will be caused. I tried MoveWindow first: the control was drawn correctly, but wouldn't drop down.

It is late Friday afternoon and I'll be closing down soon, so please excuse lack of response.

OK.
By any chance is this date time picker a standard windows control or one you have based a new class on?

Standard Windows as far as I'm aware.

By the way, the control that I copied from for both controls was 57 x 12 so it looks to me as if the shadow (for want of a better description) is just about where the graphic should go.

Thanks

Seems like we have this question twise:
http://www.experts-exchange.com/Programming/System/Windows__Programming/MFC/Q_24836590.html

I've answered there - try MoveWindow instead of SetWindowPos. I think MFC will do everything for you.

@pgnatyuk
from question  When I use MoveWindow it displays perfectly, but will not drop down the calendar.

I don't think the problem is with SetWindowPos (or MoveWindow).

You talk about many controls on the form - just how many is that?  (Don't answer - but have a quick count for yourself).
From your screen shot I count 10 - 5 with text, 1 check, 2 DateTimePickers and 2 rectangle (group box)

I seem to recall that windows can have problems when there are a lot of controls on a window (rather less than the documentation says you can have).  I know it is not trivial but you may have to consider a significant reorganisation.  Have you considered a propertysheet/page based organisation with tabs to group related controls together?

Please chek this:

GetDlgItem(IDC_COMPDATEFROM)->SetWindowPos(GetDlgItem(IDC_CHECK1),DLGX(230),DLGY(208),DLGX(63),DLGY(14), SWP_NOZORDER);

One other tip:  Try changing the tab order.  Set the calendar controls with higher numbers than other controls (I suspect that you have static or edit controls that are interfering).

To Andy comment 25642068: I tried both SetWindowPos and MoveWindow on a similar control on a less busy form and it worked perfectly. The original form has 116 controls, the less busy one has 28

To pqnatyuk: the control displayed correctly, but the calendar did not drop down

To Dan: setting tab order to 1 made no discernible difference

I played with changing tab order and there were some changes: the control with the SWP_NOZORDER parameter sometimes displayed correctly and wouldn't drop down and sometimes dropped down but wouldn't display.

Thanks

You can find which window is overlapping your control by using the Spy++ program (it's under the Tools menu).  

Start Spy++ and then press Ctrl+F.  Drag the "Finder Tool" all over your form.  You'll probably see things that you don't even realize are there!

Sorry... one more point.  
Why are you moving this control?  Usually controls are put in position at design time and stay there forever.  Perhaps there is a method other than moving the control that will accomplish what you need tto do.

Thanks guys, some interesting points above.

Just fyi, the form is used for report selection parameters.  There are now nearly 20 reports serviced by the form and controls are switched on and off and redefined as appropriate. When we needed to add another from/to date combo, it had to go where a pair of edit controls exist for another report. I thought it would be tidier to place the new controls in an unused area, and move them at run-time.

I'll put them in their place at design time and cope with the confusion.

I agree that a redesign would be a good idea.

Wow.  I'd never go that route.  I'd probably use a propertysheet with different pages to handle the variations.

I've placed the control using the IDE. I can confirm that moving it wasn't the problem, as I had to place it a few pixels away from where it really should have been, otherwise the calendar wouldn't drop.

Thanks to everyone who responded: I learned a few things even if the fundamental problem wasn't solved.

My original question wasn't able to be answered but the answers make clear the problem is more Windows based than a programming error

>>otherwise the calendar wouldn't drop.

Did you notice if it would drop down if you select it then use the keyboard command: Alt+<down arrow>

That symptom indicates that the problem is that a disabled or static control is overlaying part of the DatePicker.

There is no need to leave this question with any doubt in your mind. The control works exactly as it should. The problem lies with having too many overlapping controls. You can leave this (incorrectly) thinking there is a flaw in Windows, or you and use this as a lesson in proper U/I design. It's up to you.