|
I am using multiple threads because i am facing the same problem in a single-threaded app too.In that case too , the browsers just fires the beforenavigate and hangs.It proceeds forward with the navigation( and fires the navigatecomplete/documentcomplete events) only when i exit out of the application.
Is it essential for the client application to be a GUI based ?
|
|
|
|
|
Hi. I believe WTL is a library built to enhance the ATL windowing features. Just like we can statically link ATL's functions into our application by using the _ATL_STATIC_REGISTRY Macro, is there any way in which we can statically link the WTL library to our applications.
Thanks.
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
I think there is no such thing as linking to WTL. WTL should become a part of the application code. You can check with the Dependency Walker utility that comes with VS6.
this is this.
|
|
|
|
|
WTL is made up entirely of header files, so there's no WTL library to link with, either statically or dynamically.
|
|
|
|
|
But WTL is built on top of ATL. Although lots of ATL is header files there are parts of it that can be either statically of dynamically linked. WTL will inherit this from ATL.
Steve
|
|
|
|
|
So what you mean is, there is no wtl.dll like atl.dll for WTL? WTL is just header files which wrap aound ATL! And if I use the _ATL_STATIC_REGISTRY macro then the ATL.DLL gets statically linked to my applications along with WTL?
Thanks so much for your answers!
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|
TechyMaila wrote: So what you mean is, there is no wtl.dll like atl.dll for WTL? WTL is just header files which wrap aound ATL! And if I use the _ATL_STATIC_REGISTRY macro then the ATL.DLL gets statically linked to my applications along with WTL?
I believe so: but _ATL_STATIC_REGISTRY only controls the registration code.
Steve
|
|
|
|
|
TechyMaila wrote: And if I use the _ATL_STATIC_REGISTRY macro then the ATL.DLL gets statically linked to my applications along with WTL?
That's only needed *IF* you use the COM registration bit of ATL. I have several WTL Win32 applications. They don't link against WTL *OR* ATL libraries, as all of teh ATL and WTL code is compiled into the executable.
|
|
|
|
|
You're after the _ATL_DLL define (for the rest of ATL apart from the registration code). Also if you use ATL's ActiveX containment code it uses the type library which is in "ATL.dll" with of without _ATL_DLL defined.
Steve
|
|
|
|
|
I asked a question on the VC++ message boards about when's the best time to use a dialog based app, and when's the best time to use a normal window frame (eg. SDI, MDI etc.), and didn't receive many responses. Can anyone shed some light on this matter ?
Can someone also explain what the main differences between a dialog based app and normal frame based app (as I understand it, the main difference is that with dialog based apps one of the controls will always have the focus) ?
I'm asking because I currently have a CDialogResize based app which I wanted to add a splitter window to. Since Michael Dunn's article on WTL splitters (http://www.codeproject.com/wtl/wtl4mfc7.asp) explains using the splitter window with a normal framed window, I was wondering if it's OK to use a splitter in a dialog based app ?
|
|
|
|
|
I'm new to WTL and am using WTL 8.0 with VS 2005. I have created a new modeless dialog based app with AppWizard and then made the relevant modifications to get it to resize, according to Michael Dunn's CP article "Using WTL's Built-in Dialog Resizing Class" http://www.codeproject.com/wtl/wtldlgresize.asp
It builds OK, and my dialog gets the gripper size box in the bottom right hand corner, but when I grab it the dialog does not resize. Only the grabber size box itself moves.
I've tried comparing to other projects which work, but cannot identify any differences.
|
|
|
|
|
|
|
Hi Mike,
Thanks for taking the time to reply.
I've already got that macro in "class CMainDlg" in MainDlg.h. Does it need to be defined elsewhere ?
Have you managed to successfully compile and run the sample project I uploaded without any changes ?
BEGIN_MSG_MAP(CMainDlg)<br />
MESSAGE_HANDLER(WM_INITDIALOG, OnInitDialog)<br />
COMMAND_ID_HANDLER(ID_APP_ABOUT, OnAppAbout)<br />
COMMAND_ID_HANDLER(IDOK, OnOK)<br />
COMMAND_ID_HANDLER(IDCANCEL, OnCancel)<br />
CHAIN_MSG_MAP(CDialogResize<CMainDlg> )<br />
END_MSG_MAP()
-- modified at 21:53 Tuesday 2nd May, 2006
|
|
|
|
|
Go to resource view and change the border of IDD_MAINDLG to Resizing.
|
|
|
|
|
Thanks hfry! It's working now.
You've saved me from insanity!
|
|
|
|
|
Thank you! I have tried several times over the last 15 years to get this to work and today I know why!
|
|
|
|
|
Thank you! I have tried several times over the last 15 years to get this to work and today I know why!
|
|
|
|
|
After investigating, I see that there was a breaking change from WTL 7.0 to 7.1. The third param to CDialogResize::DlgResize_Init() is styles to add to the window. This changed from WS_THICKFRAME|WS_CLIPCHILDREN to just WS_CLIPCHILDREN.
As the other post said, the best way is to set the dialog's border to Resizing in the resource editor. (Not doing that, even in WTL 7.0, creates a positioning glitch in XP with themes turned on.)
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Thanks for taking the time to look into it Mike, and for providing an explanation of why it wasn't working. I have now done what hfry suggested and all is working fine now
It's not important for me now, but I'm sure anyone else who delves into CDialogResize would appreciate it if you updated both your WTL articles which mention CDialogResize to include this snippet of info.
1) Resizing Dialogs section of WTL for MFC Programmers, Part V - Advanced Dialog UI Classes
2) Using WTL's Built-in Dialog Resizing Class
Thanks again for your help. I can now continue development of my world beating, super efficient resizable About dialog 
|
|
|
|
|
Hi to all,
i am using IHTMLButtonElementEvents2 interface. when i am going to compile , i am getting following error.
error LNK2001: unresolved external symbol _DIID_HTMLButtonElementEvents2
if someone having idea then reply.
|
|
|
|
|
|
thanks,
but i tried with uuid.lib only,
which is also not working
|
|
|
|
|
Try using __uuidof(HTMLButtonElementEvents2) instead.
Steve
|
|
|
|
|
You can look and see what's inside a lib. Use the following command with the current directory in the lib folder:
dumpbin /LINKERMEMBER:1 UUID.LIB
I done this on MSVC6's "UUID.LIB" and it contains _DIID_HTMLButtonElementEvents but not _DIID_HTMLButtonElementEvents2.
When I done it on the February 2003 Platform SDK's "UUID.LIB" I found both _DIID_HTMLButtonElementEvents and _DIID_HTMLButtonElementEvents2.
This suggests you are compiling with the header files from one SDK (newer) but linking with the libraries of an older SDK. I'd check your include and library paths.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
