|
Hi everybody
I am developing an internet explorer toolband, with many functions, one of them a popup blocker button. I was searching in the examples, but all the examples have ATL or MFC functions, and i need do all that things without using any ATL or MFC functions.
If anybody can helpme i will be gratefull
|
|
|
|
|
Without using MFC and ATL
u will need to lots of stuff by ur self.
Must rewrite all the MFC function used in
ur program .
And if u mean to create a pop-up blocker
might be u need to use window messages
so win32 can come to ur resuce.
DLL's can help u but i cant say it for sure
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
neliocc wrote: . I was searching in the examples, but all the examples have ATL or MFC functions,
Buddy, it would be easier if you use ATL to develop toolband application for IE, as IE provide automation support for same.
but if you still insist on using pure Win32 Api, here is hint...
you have to create the dll, which contain the Window Which subclass main window for Window Message... also another application which inject this dll into process space of IE ( for that you have to create system wide hooks). not the easy task, but i believe thats the only way to get there.
you have to Hook the system for IE instance...
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
I think you should look into creating a Browser Helper Object (BHO).
|
|
|
|
|
I'm stepping through my disassembled code:
<br />
*buffer2 = *buffer1; QUESTION 1<br />
<br />
00411AED cmp byte ptr [ebp-119h],0 QUESTION 2<br />
00411AF4 jne main+0D3h (411B03h) <br />
00411AF6 push 411B6Bh <br />
00411AFB call @ILT+555(__RTC_UninitUse) (411230h) <br />
00411B00 add esp,4 <br />
00411B03 cmp byte ptr [ebp-10Dh],0 <br />
00411B0A jne main+0E9h (411B19h) <br />
00411B0C push 411B63h <br />
00411B11 call @ILT+555(__RTC_UninitUse) (411230h) <br />
00411B16 add esp,4 <br />
00411B19 mov eax,dword ptr [buffer2] <br />
00411B1C mov ecx,dword ptr [buffer1] <br />
00411B1F mov dl,byte ptr [ecx] <br />
00411B21 mov byte ptr [eax],dl <br />
QUESTION 1
*buffer2 = *buffer1;
How's this one line translated to this this big chuck of disassembly? (I'm assembly newbie, playing with WinDbg, going thru instruction sets and trying to see things in action)
And, the first line of disassembly is a CMP instruction??
QUESTION 2
00411AED cmp byte ptr [ebp-119h],0 QUESTION 2
okay, is "ptr" a keyword? References? Also, is "byte" a keyword?
I'm looking at WinDbg's manual, the reference is... less than ... For example:
MOV r1, r/m Move with zero extension.
It doesn't state if parameter 1 is source or destination! Any good reference source?
QUESTION 3
How come "main" does not start with address 00000000? #include "stdafx.h" #include <stdio.h> int _tmain(int argc, _TCHAR* argv[]) { 00411A30 push ebp 00411A31 mov ebp,esp 00411A33 sub esp,120h
When I run WinDbg,
ModLoad: 00400000 0042c000 C:\development\Samples\TestDebugger.02\Debug\TestDebugger.02.exe
ModLoad: 77f50000 77ff7000 C:\WINDOWS\System32\ntdll.dll
ModLoad: 77e60000 77f46000 C:\WINDOWS\system32\kernel32.dll
Where's 00000000 to 00400000? What's in it?
QUESTION 4
Where's the "stack", is there a memory address...? Is EBP register the "address" of stack location in process memory/address space? And ESP (stack pointer) pointing to top of stack - but is it just a relative/offset from EBP? I assume EBP is "absolute" address based 00000000 (ie. start of process address space), am I right or wrong?
QUESTION 5
These addresses I see on stack trace, for example, 00411AED, is it "Virtual"? Where's the "zero" point?
Thanks in advance.
Norman Fung
|
|
|
|
|
So much of code is added to check for runtime errors:
First of all, checks are performed...
00411AED cmp byte ptr [ebp-119h],0 (check if buffer1 has been initialized or not)
00411AF4 jne main+0D3h (411B03h) ( if initialized, check for next value)
00411AF6 push 411B6Bh ( else push some sort of argument for function __RTC_UninitUse on the stack )
00411AFB call @ILT+555(__RTC_UninitUse) (411230h) ( call the error handler )
00411B00 add esp,4 ( pop value from the stack )
00411B03 cmp byte ptr [ebp-10Dh],0 ( check buffer2 )
00411B0A jne main+0E9h (411B19h)(...)
00411B0C push 411B63h (...)
00411B11 call @ILT+555(__RTC_UninitUse) (411230h)(...)
00411B16 add esp,4(...)
Actual work starts here:
00411B19 mov eax,dword ptr [buffer2] (store the buffer2 pointer in eax)
00411B1C mov ecx,dword ptr [buffer1] (...)
00411B1F mov dl,byte ptr [ecx] (copy a byte to dl from address pointed to by ecx)
00411B21 mov byte ptr [eax],dl ( copy a byte from dl to the address pointed to by eax )
done 
"Do first things first, and second things not at all."
— Peter Drucker.
|
|
|
|
|
Hey thanks that's very helpful, but where's the stack in memory. I used WinDbg to lookup memory allocated for loaded "exe", as well as that for system services "ntdll" and "kernel32":
ModLoad: 00400000 0042c000 C:\development\Samples\TestDebugger.02\Debug\TestDebugger.02.exe
ModLoad: 77f50000 77ff7000 C:\WINDOWS\System32\ntdll.dll
ModLoad: 77e60000 77f46000 C:\WINDOWS\system32\kernel32.dll
But where's the stack? Each process gets its own address space. Is stack allocated in 00000000 to 00400000 (Before the "exe" address block)? How big can a stack gets?
Norman Fung
|
|
|
|
|
Hey thanks, that's very good ... I got another question:
00411B19 mov eax,dword ptr [buffer2] (store the buffer2 pointer in eax)
00411B1C mov ecx,dword ptr [buffer1] (...)
Why not write this:
00411B19 mov eax,dword ptr [buffer2] (store the buffer2 pointer in eax)
As:
00411B19 mov eax, ebp + 0xsomeoffset
Perhaps it's because the buffer is on the "heap" and not on "stack"? But how does the CPU knows of the symbolic token [buffer1] ...? I thought everything is memory buffer with address in assembly level.
And why "dword" and "ptr" in the instruction? I understand "dword" = 32 bits (well, I guess this is why because it specify buffer size so "mov" command can move buffer of right size... am I right?) and "ptr" = pointer... but why... do we need this in the argument?
Norman Fung
-- modified at 22:38 Wednesday 21st December, 2005
|
|
|
|
|
Hi
I am having a hook DLL. I am hooking only the explorer process using the SetWindowHookEx function. Inside the dll I am creating a window. I am able to create the window and receive the messages. When I try to release the hook explorer.exe is throwing an exception.I tried sending WM_DESTROY message to the window created when i am releasing the hooks, but its not working. Any idea on how to overcome this problem. Thanks in advance.
Thanks.
|
|
|
|
|
When I assign long text to CListCtrl, it displays only a part of them (200-300 characters - not sure) and then it cut off with no clue (without dots). I still get full text from fuction GetItemText.
CListCtrl Auto ToolTip have problem too. ToolTip length is out of screen. (My text don't have any space.)
How do I fix these? I am too lazy to override CListCtrl class.
-- modified at 22:30 Tuesday 20th December, 2005
|
|
|
|
|
Hi,
I am trying to get a modeless property sheet running.
I am using the PropertySheet() function to start the property sheet + also add PSH_MODELESS to make it a modeless dialog.
I am receiving the return value of the PropertySheet() function to get the propsheet window handle.
I think this all works fine. The dialog appears and the tabs which are in look okay as well. The thing now is that it cannot be closed anymore correctly or behaves weird.
The strange thing with the property sheet is that there is no way to pass a Message Proc to the property sheet (as far as i have seen), so i had to put some message loop myself after creating the dialog. This is how it looks:
<code>
MSG Msg;
while(GetMessage(&Msg, NULL, 0, 0))
{
if(!IsDialogMessage(mainHwnd, &Msg))
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
HWND pageHandle = PropSheet_GetCurrentPageHwnd(mainHwnd);
if (pageHandle == NULL || (Msg.message == WM_COMMAND && Msg.wParam == IDCANCEL))
{
for (int i=0; i<mPropertySheets.GetLength(); ++i)
PropSheet_RemovePage(mainHwnd, 0, NULL);
EndDialog(mainHwnd, 1);
break;
}
}
}
</code>
If i don't put the "if (pageHandle == NULL..." in then i am not able to close the modeless dialog  And if i put that in it sometimes works and sometimes i have to press the "OK" button 10 times till it recognizes it.
I hope anyone can help me. I would appreciate it a lot!
Thanks in advance for your time.
- Benjamin
|
|
|
|
|
Hello,
I have a c++ program that must receive windows messages from a c# program. This is a console application. Here is what my code looks like for receiving the messages...
CWnd::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if(message == REPLY_PICTURE_READY)
...
else if(message == REPLY_PICTURE_ERROR)
...
}
This does not compile, am I on the right track for receiving messages? Since this is a console application, and it can not skip around the code like in a gui, I would need to call this function in my code right? Or would I need to use threads? I would appreciate some input on this
Very Confused
|
|
|
|
|
Can you give more information about de application that 'sends' those window messages? Give the piece of code that sends the message. Make sure both the sender and the receiver have knowledge of the windowmessage (use RegisterWindowMessage for this).
Also, I have no experience with capturing window messages in a console program. Is this really possible? Maybe this is why you can't compile the piece of code.
If you make you receiver program a window based program (using WinMain and CreateWindow to create an initial window) Your sender program will send its message to the window of the receiver program (trough the callback function)
Anyway, if you give more information about your problem, I might be able to help you further.
kind regards,
Ward
|
|
|
|
|
>>Can you give more information about de application that 'sends' those window messages?
this is where things get complicated, the other program is window based program written in c#. The c++ program can send a message to the c# program just fine, but i'm having trouble reversing this.
>>Give the piece of code that sends the message. Make sure both the sender and the receiver have
>>knowledge of the windowmessage (use RegisterWindowMessage for this).
this is the code from the c# program that sends the message...
[DllImport("user32.dll", SetLastError=true, EntryPoint="SendMessage", CharSet=CharSet.Auto)]
public static extern IntPtr SendMessage(IntPtr hWnd, uint Msg,IntPtr wParam,IntPtr lParam);
SendMessage( camController_Handle, REPLY_PICTURE_READY, IntPtr.Zero, IntPtr.Zero);
the messages being sent between the programs are registered in the following manner...
UINT REPLY_PICTURE_READY = RegisterWindowMessage("REPLY_PICTURE_READY");
^this is done in the c# program too, slighty modified, but it compiles fine.
>>Also, I have no experience with capturing window messages in a console program. Is this really >>possible? Maybe this is why you can't compile the piece of code.
This could be a very real possiblity, however I could not dig up anything to prove it. The console program can send the messages just fine, so why can't it receive them? Anyone know anything about this? Or specifically how a console program can receive custom messages?
mildly frustrated
|
|
|
|
|
What is that handle 'camController_Handle' you are sending the message to? Since you want to send the message to a console program, which has no windows, I think you better broadcast your message:
SendMessage(HWND_BROADCAST, REPLY_PICTURE_READY,IntPtr.Zero, IntPtr.Zero);
But then it is unsave to 'SEND' a message to another program. Your C# application could get blocked. Better use PostMessage(HWND_BROADCAST, REPLY_PICTURE_READY,IntPtr.Zero, IntPtr.Zero);
To capture window messages in a console program, try:
<br />
#include <windows.h><br />
int main()<br />
{<br />
UINT uiREPLY_PICTURE_READY = RegisterWindowMessage("REPLY_PICTURE_READY");<br />
MSG msg;<br />
while (GetMessage(&msg, NULL, 0, 0)) <br />
{<br />
if(uiREPLY_PICTURE_READY == msg)<br />
{<br />
}<br />
}<br />
}
The above might not work (I have not tested it) since GetMessage might need at least one window in the console application. You can always create a simple hidden window using CreateWindow.
I the above tips do not work, contact me again.
kind regards,
Ward
|
|
|
|
|
Roy K wrote: This does not compile...
Why? What's the error message?
Roy K wrote: ...I would need to call this function in my code right?
No. WindowProc() is never called directly. It is called by the framework.
Roy K wrote: Since this is a console application...
So why do you have a CWnd reference?
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Hi
I have a CSliderCtrl which I have placed within a CDilaogBar. As soon as the control gets focus a dotted rectangle appear around it. How can I get rid of this? Is there some style which I can change? I don’t get the rectangle at all when its on a plain CDialog.
Cheers
Rich
|
|
|
|
|
Handle the reflected NM_CUSTOMDRAW and then clear the CDIS_FOCUS flag from theNMCUSTOMDRAW::uItemState during the CDDS_PREPAINT stage.
|
|
|
|
|
VC6
I can't use the MFC-supplied tooltip handling (on a CFormView) because it doesn't return tooltips for a static control (with an ID) or for CDateTimeCtrl, so I've come up with my own code.
I've got my tooltips showing up, but they appear to not be "on top". By that, I mean the tool tip shows up, but it's partially hidden by any controls that might occupy the same part of the screen.
I've tried BringWindowToTop(), as well as SetWindowPos(&Cwnd::moveToTop, ...), and even SetWindowPos(Cwnd::FromHandle(HWND_TOP), ...).
Any help?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Are you using the WS_EX_TOOLWINDOW style as well as WS_EX_TOPMOST. Also try making it a child of the desktop so that it is not a sibling of the controls on your form.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
I'm calling ::GetSysColor(COLOR_INFOBK), and it's returning white, despite the fact that my tooltip background color has been set to yellow. Does anyone have any ideas?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Does GetSysColorBrush(COLOR_INFOBK) work?
Bernie (Boom Boom) Geoffrion worked Atlanta Flames games in the 1970s with the splendid Jiggs McDonald. One night, Geoffrion said, "Jiggs, there are only three things to hockey: shooting and skating." McDonald said, "Right, Boomer. And what's the third?" The exasperated Geoffrion replied," Jiggs, that's the three. Shooting. And. Skating."
|
|
|
|
|
Well, since this particular color definition has been available since win95, i think i can be pretty sure that function will work. BTW, I'm getting the color for the text (COLOR_INFOTEXT).
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: i think i can be pretty sure that function will work.
One would think that GetSysColor would work too, but in your case it appears to not be. GetSysColorBrush will return NULL on error, where as GetSysColor does not have a reliable error check mechanism. Also if GetSysColorBrush(COLOR_INFOBK) also returns a white brush then your system settings may not be what you think they are.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Actually, it was stupid programmer tricks. My fault entirely. 
Nevermind.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
