|
Now that I think about it more, the MapWindowPoints() isn't necessary since you only need
the size of the tabs control, not it's position. You can probably eliminate that call.
The important part is using GetWindowRect instead of GetClientRect.
|
|
|
|
|
I still get the same result with that code. But that gave me an idea. Here's what I did to fix it.
CRect MainDialogRect, LoadDialogRect;
GetParent()->GetWindowRect(&MainDialogRect);
pLoadingDlg->GetWindowRect(&LoadDialogRect);
pLoadingDlg->MoveWindow(MainDialogRect.left + ((MainDialogRect.Width() - LoadDialogRect.Width()) / 2),
MainDialogRect.top + ((MainDialogRect.Height() - LoadDialogRect.Height()) / 2),
LoadDialogRect.Width(), LoadDialogRect.Height());
I found that I was always getting the correct coordinates, just relative to the wrong point (screen origin vs window origin). So I added the location of the main window to the coordinates.
|
|
|
|
|
Whatever works. Seems weird (obviously, or you would't have asked about it in the first
place) that you'd get screen-relative coordinates from GetClientRect()...
|
|
|
|
|
Yeah that IS very unusual. Maybe something to do with the fact that it's a tab window. Who knows what actually goes on in the GetClientRect() function. Maybe you do, but I sure don't. You are clearly much more experienced in VC++ than me.
|
|
|
|
|
acerunner316 wrote: Maybe you do, but I sure don't.
Not me. 
I dug in my existing code and saw I was mapping the window rect points like that second code
I posted (in my case I handle the tab control and all the associated tab windows from the tab's
parent window class so it's a little different).
Regardless, the MoveWindow call should move the child window relative to it's parent's client area.
 Beats me!
|
|
|
|
|
Another question, since the two tabs does very similar tasks and functions, is it possible to use the same dialog class for both tabs, but different resource dialog (ie IDD_TAB1 and IDD_TAB2 both associated with CTabDlg)? The layout will be different, but I will be reusing most of the same functions.
|
|
|
|
|
Yes it's possible. You'll need to create with the appropriate resource ID.
You can also use a common base class containing the code for the controls they have in common
and derive 2 classes, each with whatever code they need for the unique parts of the dialogs.
|
|
|
|
|
When I create a new dialog in resource editor and I use class wizard to assign an existing class to it, I get a warning that the dialog class definition is already using another resource. It asks if I want to change it to the new resource, but I don't want to change it, I want it to use both resource...
Is this the correct way to do it?
The 2 derived classes sounds like the best solution. I would have to remap all the controls from the existing tab window though. It will take longer, but I think in the long run, this is the better option.
|
|
|
|
|
acerunner316 wrote: Is this the correct way to do it?
Yeah I didn't think about how the class wizard would react I guess some hand-coding/rearranging
will be necessary.
acerunner316 wrote: I would have to remap all the controls from the existing tab window though
If you choose to go that route, use the class with the most code already in it. Copy the
cpp and h files and rename to the base class name or whatever. In the files find/replace all
instances of the old class name with the new name.
That'll save much work.
|
|
|
|
|
The class wizard doesn't seem to allow creating a derived class from a derived class. In the Add New Class dialog box, there is no selection for user defined classes, just the standard Windows classes.
|
|
|
|
|
That has to be changed by hand as far as I know. I usually derive from the known (by the class
wizard) class (CDialog) and then change all the CDialog to CMyDialog. This is way easier after
all the controls and control message handlers have been added using the wizard.
Later, if controls are added or removed I just do it by hand, since there's already code there
to copy from.
It's a fact of life with an advanced UI layout
Someday the wizards will learn from the way we do things and adapt....I hope!
|
|
|
|
|
Hello,
I am having real trouble figuring out how to use CInternetSession, CHttpFile, and the like to interact with web servers and download content.
Is there anyone here with experience using these classes?
Specific Questions:
Am I supposed to use either OpenURL OR create a CHttpConnection, but not both?
Am I supposed to first call CHttpFile::SendRequest() and then wait for it to call my StatusCallback function, then start reading from the CHttpFile?
Why does the CHttpFile not show any response even though the callback function says that a response has been received?
--------------------------------
"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
|
|
|
|
|
Richie308 wrote: Has anyone used the MFC Internet Classes?
No. No one has ever used them.
Richie308 wrote: I am having real trouble figuring out how to use CInternetSession, CHttpFile, and the like to interact with web servers and download content.
You mean like in the instructions that they hid in the documentation[^]?  
led mike
|
|
|
|
|
Your post is not helpful. Better to say nothing than say garbage like that.
The documentation is obviously not answering my questions. If you have something to contribute, then do so.
--------------------------------
"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
|
|
|
|
|
Well I wouldn't want you to have to read any documentation so here use this article [^]and you can just copy paste your code.
led mike
|
|
|
|
|
That's fine for synchronous use of the classes, but I'm trying to use them asynchronously.
--------------------------------
"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
|
|
|
|
|
Richie308 wrote: I'm trying to use them asynchronously
Can you do that with the MFC WinInet classes (well, aside from using a separate thread)?
|
|
|
|
|
Mark Salsbery wrote: Can you do that with the MFC WinInet classes (well, aside from using a separate thread)?
I don't know, and the documentation doesn't provide an answer either way.
--------------------------------
"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
|
|
|
|
|
Check this out (code samples): WinInet Basics[^]
From the CInternetSession::EnableStatusCallback docs:
"To handle any operations asynchronously, you must either create your own thread or use the
WinInet functions without MFC."
|
|
|
|
|
Anybody can miss any specific sentence buried in the documentation.
This is supposed to be a help board, not a stick-it-in-your-face board.
--------------------------------
"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
|
|
|
|
|
If quoting it here didn't help then sorry. It was easier to copy/paste than to type it.
|
|
|
|
|
Richie308 wrote: the documentation doesn't provide an answer either way.
As posted in another reply... yes it does. MSDN online has almost everything. Google performs the best searches of MSDN material. Put "MSDN" as the first keyword in your google search input. Figuring out what keywords to use is the... ummm ... key  to researching these days. In case Bob is listening.... of course Articles at CodeProject are another great resource.
led mike
|
|
|
|
|
Richie308 wrote: I'm trying to use them asynchronously.
You never said that until now.
Google is your friend: "MSDN WinInet MFC"
finds: http://support.microsoft.com/kb/164983[^]
SUMMARY
The MFC WinInet classes (CInternetSession, CInternetConnection, and so forth) are not designed to be used with asynchronous WinInet connections or file transfer. Instead, developers looking for asynchronous-like behavior in their MFC WinInet application should implement separate synchronous WinInet sessions in secondary threads.
led mike
|
|
|
|
|
led mike wrote: You never said that until now.
Well you would not have known, because you initially responded with childish sarcasm, instead of like a helpful human being.
--------------------------------
"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke
|
|
|
|
|
Richie308 wrote: because you initially responded with childish sarcasm, instead of like a helpful human being.
For a few poeple, the sarcam will help them understand the need to develop skills related to finding information and reading it rather than having to rely on others for help. Others who can help because they did read the documentation. For those few that heed the message, they will significantly improve thier development skills. For the rest that don't heed the message but rather complain about the delivery, they will continue to struggle but that is their choice. A few insults and complaints hurled at me by lazy people that won't amount to anything anyway are worth bearing if I may help even a single person become a "professional" developer. But if you prefer to whine about it go right ahead, it has no effect on me.
Also, no one knew about your async requirement because you didn't post it, not for any other reason.
led mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
