Click here to Skip to main content
15,911,891 members
Home / Discussions / .NET (Core and Framework)
   

.NET (Core and Framework)

 
GeneralRe: Installshield Pin
James T. Johnson2-Feb-02 11:28
James T. Johnson2-Feb-02 11:28 
GeneralRe: Installshield Pin
James T. Johnson2-Feb-02 17:58
James T. Johnson2-Feb-02 17:58 
GeneralRe: Installshield Pin
Mazdak2-Feb-02 20:24
Mazdak2-Feb-02 20:24 
GeneralRe: Installshield Pin
James T. Johnson2-Feb-02 20:27
James T. Johnson2-Feb-02 20:27 
GeneralSmart Device Extensions Pin
Tim Ranker31-Jan-02 12:45
Tim Ranker31-Jan-02 12:45 
GeneralRe: Smart Device Extensions Pin
James T. Johnson31-Jan-02 14:38
James T. Johnson31-Jan-02 14:38 
GeneralRe: Smart Device Extensions Pin
Tim Ranker31-Jan-02 15:52
Tim Ranker31-Jan-02 15:52 
GeneralMDI Form.Show destroys Form.Location Pin
30-Jan-02 7:33
suss30-Jan-02 7:33 
Problem 1:

If I temporarily hide an MDI child Form and then show it again like this...

myForm.Hide ();
...
myForm.Show ();

...then the Location is chosen at random as if this was the very first time the Form is displayed.

I work around the problem like this:

Point priorLocation = myForm.Location;
myForm.Show ();
myForm.Location = priorLocation;

But that causes a gross visual blunder as the window is initially displayed in a random position and then jumped to its new position.

I tried using the underlying ShowWindow API on the window handle and that solves the location problem but unfortunately does even nastier things to the entire .NET Form internal state. (Windows don't show as being active, etc.)

Does anybody have a technique for preserving the location of an MDI child Form that does not have a visual glitch?


Problem 2:

Maybe this is not related but when I (re)Show a child Form, an ActiveX object embedded on that form likes to draw itself on the desktop instead of in the child window. Any ideas here?


Eric Newhuis
enewhuis@futuresource.com
GeneralRe: MDI Form.Show destroys Form.Location Pin
James T. Johnson30-Jan-02 9:53
James T. Johnson30-Jan-02 9:53 
QuestionStill COM+ in .NET for multi-thiered programming? Pin
Amanjit Gill27-Jan-02 5:52
Amanjit Gill27-Jan-02 5:52 
AnswerRe: Still COM+ in .NET for multi-thiered programming? Pin
Andres Manggini15-Feb-02 14:22
Andres Manggini15-Feb-02 14:22 
QuestionCan I use VC .NET to develop traditional mfc apps? Pin
25-Jan-02 3:14
suss25-Jan-02 3:14 
AnswerRe: Can I use VC .NET to develop traditional mfc apps? Pin
NormDroid25-Jan-02 3:31
professionalNormDroid25-Jan-02 3:31 
GeneralRe: Can I use VC .NET to develop traditional mfc apps? Pin
Hadi Rezaee27-Jan-02 10:03
Hadi Rezaee27-Jan-02 10:03 
GeneralRe: Can I use VC .NET to develop traditional mfc apps? Pin
NormDroid27-Jan-02 21:37
professionalNormDroid27-Jan-02 21:37 
GeneralRe: Can I use VC .NET to develop traditional mfc apps? Pin
28-Jan-02 4:08
suss28-Jan-02 4:08 
QuestionUsing VC6 and VS.NET on the same machine? Pin
Aza24-Jan-02 0:22
Aza24-Jan-02 0:22 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
Peter Stephens24-Jan-02 6:52
Peter Stephens24-Jan-02 6:52 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
Not Active24-Jan-02 7:18
mentorNot Active24-Jan-02 7:18 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
James T. Johnson24-Jan-02 12:14
James T. Johnson24-Jan-02 12:14 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
Tim Smith24-Jan-02 12:23
Tim Smith24-Jan-02 12:23 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
Valer BOCAN24-Jan-02 21:51
Valer BOCAN24-Jan-02 21:51 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
Nish Nishant24-Jan-02 23:06
sitebuilderNish Nishant24-Jan-02 23:06 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
Aza25-Jan-02 2:23
Aza25-Jan-02 2:23 
AnswerRe: Using VC6 and VS.NET on the same machine? Pin
19-Feb-02 20:43
suss19-Feb-02 20:43 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.