|
Hey Friends
Is it possible to disable events of a HTMLElement?
Let's say in html code, there are events defined for some html elements
Let's say <a href="some link" onselect="something here">Click Here</a>
Now i host a webbrowser in my dialog based app and i do not want custom onselect event to be fired(i.e something here above)
may be something we can do with
IHTMLElement * pElem = NULL;
IHTMLElement2 * pElem2 = NULL;
IHTMLElement3 * pElem3 = NULL;
all above interfaces have put_ functions but if i pass NULL, it means to them default behavior (i.e onselect="something here")
or i can define function in my .cpp file to be called
i do not want any of the above
i just want htmlelement not to call
onselect="something here"
that's it
Any Ideas?
Regards
|
|
|
|
|
There isn't one place where all events are received. You can only divert one event at a time if you want to deal with events.
However, IHTMLElement3 has disabled attribute that you can set to TRUE. This will disable any interaction with that IHTMLElement. Of course, first you have to reach that element.
Other than that you can set the parent window as disabled and then you would not be able to do anything with that HTML control.
|
|
|
|
|
hi
thanks for the help
i do not want to disable complete html element
i just want to disable a specific dhtml event
onclick, onfocus seperately
|
|
|
|
|
Use detachEvent but you have to find the event first.
|
|
|
|
|
yeah thanks
will try it now and will update
|
|
|
|
|
IHTMLElement * pElem;
IHTMLElement2 * pElem2;
//Get pElem & pElem2
CString vl_sHelper("onclick");
COleVariant vl_oOnClick;
pElem->get_onmouseover(&vl_oOnClick);// This should get the onclick event?
pElem2->detachEvent(vl_sHelper.AllocSysString(),vl_oOnClick);//COleVariant to IDispatch* sounds strange to compiler
|
|
|
|
|
It does because it is.
Why COleVariant, can't you use VARIANT of type VT_DISPATCH? It is easier.
And pElem and pElem2 should be the same element.
|
|
|
|
|
yeah thanks
compiled and ran successfully detachEvent returns SUCCESS
however, seems something is missing
it still calls the event written in html 
|
|
|
|
|
hey buddy
thanks for the help
found a workaround
1st find out the event
then
get outer html
modify outer html
put it back
not good
but works
|
|
|
|
|
It is not a bad solution. However, detachEvent should work as well. It works if you would write from JavaScript code in HTML page. But, any solution is a good solution as long as it does the job efficiently. 
|
|
|
|
|
Hello from a self-taught MFC bumbler...
I have to prototype a simple dialog-based MFC app which will serve as a front-end to an old dinosaur 3rd-party
MDI GUI app. Without naming names, lets call the 3rd-party app ABF. (More background at the bottom)
I have been able to inventory the main system windows for the main ABF window, and all its child windows, including the MDI frame,
menu bars, status line, and various pop-up output windows (CEdits) which show the user success/failure messages. Ive been successful
sizing/min/maxing all these windows, so I can pretty much drive what the user sees in ABF from my MyAPP, which, btw, appears
to the user simply as a clamped-on toolbar on the right of the main ABF window.
Ive been mostly successful driving all the necessary ABF menu pulldowns, providing the input keystrokes and Mouseclicks, and then
reading the output window(s) for success/failure strings. All except for a few specific cases. These problem cases are why
Im posting here. Essentially, I have been successful with...
*) Finding the main ABF window, and any/all child windows owned by such.
*) popping ABF to the top, and sending keys to invoke menu pulldowns, fill in edit boxes with
data, and send {ENTER} to OK and close the dialog.
*) Finding and reading the new output window that tells the success/failure of the operation. (& creates disk files)
Here are the rough (extracted ) lines from my code to do this.
<br />
DWORD tWNDthread = ::GetWindowThreadProcessId(hwndTARGET,0);
BOOL bAttached = AttachThreadInput(GetCurrentThreadId(),tWNDthread,TRUE);
::SetForegroundWindow(hwndTARGET);
::SetFocus(hwndTARGET);
AttachThreadInput(GetCurrentThreadId(),tWNDthread,FALSE);
::SendInput(KBn,&KBa[0],sizeof(INPUT));
...After that, like I said, I can inventory all child windows of hwndTARGET, and find the new output window, which has a main CEdit. I read
this CEdit, and it tells me the success or failure of the operation I just invoked.
Like I said this works, MOSTLY. The only time it doesn't work is when the user invokes a menu-pulldown of his own, and a big fat
dialog box is already presented to the user. When this is the case, My apps normal SendKeys dont make it to the main window, nor the
child dialog. (I dont know where they end up). What I do know, is that my interface is hosed. What Id like to do is prefix my SendKeys
with a few ESCAPES, so I can close all child dialogs before I try and invoke my own pulldowns. But this doesnt work. I dont know why.
So, before I spend far too many of my man-days trying to debug this, I thought Id post here and get some expert opinion.
So, here are my specific questions.
A) When ABF has some dialog window sitting in front, it DOESNT appear anywhere in the Main-ABF-Window's child window list. (???) Thus, I
dont know that it even exists (so I cant detect the problem state). What calls can I use to know if such a window is on-top.
B) Are these dialog windows totally invisible to me? Or can I do some inventory of windows owned by the ABF THREAD, (and not the
main ABF WINDOW). Is this where I should be focusing my strategy?
C) Ive been able to read CEdits (only) from some other ABF Main-Window-owned child dialogs, but there are [X]checkboxes that I need to read
the state of. I can change the state of them (because mostly everything has an accellerator key thankfully), but I dont know how to READ
the state of the checkboxes when the dialog is on top. Same goes for comboboxes and other std dialog elements.
OK, I guess thats enough to get me going again.
All answers are much appreciated. Remember, I havent had any formal MS education. My windows knowledge is all self-taught
through MFC-by-example books and the likes.
Dave (from Pittsburgh)
p.s. Running MFC6.0 on NTsp2
(p.p.s. If you're in Pittsburgh, a little *paid* consultation time might be considered.  Im behind schedule)
DaveB 412-374-6781
-----more background------
ABF is a 15 year old product that we paid a boxcar full of money to have qualified for use in a safety-critical
development process. Its designed to have a user in front of it, who reads inputs through his eyes. He will then
do ABF menu pulldowns, which invoke dialog boxes where he enters the data he sees, etc. In the end, the outputs go
through a tedious validation and verification process. Its very painful and tedious, and very prone to human error,
because the operator has enter roughtly 175000 data-items for a typical job. We're pretty locked-in to this
product. Because of this, we're assured that the ABF product is NEVER going to change, or be upgraded for us.
Also, because of our formal development process, I cannot just hack the ABF fileformat. Im FORCED to enter data through the
ABF tool. It provides a ton of unknown data-checks and conversions. I just want to bypass the error-prone user-input part.
I was awarded some research funds to try and develop an APP which will try and drive ABF from another dialog app.
If I can get even a modest prototype functioning, my Co will sponsor a rigorous development plan which will employ some real
programmers to design a formal-interface. Ive got to proof the concept first, however.
"Help Me Obi-Wan-CodProjbi, you're my only hope."
|
|
|
|
|
If I understand Windows and dialogs and menus correctly, modal dialogs and popped-up menus have their own message loop (it's called a modal loop because the application enters a different mode when menus or modal dialogs are displayed). Again if I understand correctly, these will swallow all the messages you send to the main window and discard them or something.
So - I suspect you're hosed when modal dialogs or menus are displayed.
But I could be wrong
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Yes, most of these dialogs ARE modal. But I can stuff my whole begin-to-end keysequence
into a single SendInput sequence, and the main loop will forward subsequent keystrokes to any newly created
modal child dialog. For example, If I stuff SendInput with "{ALT}FGMyFile.xyz{ENTER}", then:
a) the sequence {ALT}FG Executes the FILE --> Generate File modal dialog. (which *IS* Modal)
b) then, within that dialog, the keys "MyFile.xyz" get stuffed into the first (default)
output filename CEditbox
c) and the final {ENTER} closes that modal dialog (because the OK button has the WantReturn property), and thus
the dirty deed is accomplished.
So, I get success when I do SENDINPUT of "{ALT}FGMyFile.xyz{ENTER}"
But I get failure when I do SENDINPUT of "{ALT}FGMyFile.xyz"
followed by another SENDINPUT of "{ENTER}"
The second SENDINPUT still tries to send to the main ABF hwTARGET, but its fubar'd
by the Modal dialog, which now has input focus, but which isnt catching any further input from my app(???).
Evidently, the Generate-File modal dialog isnt a child-window of the main app window. (but of something else instead???).
It doesnt appear after all my EnumerateChildWindows callbacks.
My questions really are. Are these dialogs *really* still children of the main window, (but maybe they're
hidden somehow, and not subject to EnumerateChildWindows?) Maybe I can find them through more painfull digging...
-or- are the modal dialogs NOT child windows of the main window, but of the main application thread instead.
And is there a way to enumerate *all* child windows of the main thread(s)? And if I find them, can I
send them direct KEY messages. (like {ESCAPE}s, just to close em)
p.s. Yes, I know a SETFOCUS followed by a targetless SENDKEYS is very sloppy, especially if the user decides
to do some multitasking, or if there are other apps around which steal input focus. Id much rather send directed
WM_KEYDN/UP messages, but I havent been able to make that work, especially since there's no security relationship
between my app and the ABF app.
All I want to do is be able to detect if there are any active modal ABF child windows, and send them {ESCAPE}
messages to close em down before my app can try its own commands.
Thanks for the response though. I learn tons from every reply.
-Dave
|
|
|
|
|
Wibble - you've done a lot of this SendInput stuff, haven't you! Let me commend you on your fortitiude
The only thing I'll ask is if a Windows macro app like this one[^] can do what you've been trying to get working? Knowing if something's possible (or not) can help...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hey Buddy
Yes you are at correct place, but i may not be of much help.
SendInput is a risky thing as you have faced already
If you get HWND of the target window, then you can treat them with your own classes
Let's say you get an edit box
CEdit* vl_pEdit = (CEdit*)CWnd::FromHandle(targethWnd);
if(vl_pEdit && IsWindow(vl_pEdit->m_hWnd))
{
//you have got CEdit
//Call GetWindowText or SetWindow Text
}
Same would be applicable to CheckBoxes
Use CButton::GetCheck() for getting state
Also
to Click on a Dialog Box, given below is an encrypt from experts exchange which requires subsription and hence pasting below
http://www.experts-exchange.com/Programming/Languages/Q_20572990.html[^]
So you can do many things without SendInput & that too in a reliable way.
However it seems you have developed functionality using SendInput and hence this information may be of little use to you, still posting here, whatever i can.
-----------------------Starts-----------------
The proper WM_COMMAND for a button click is:
PostMessage(hWndParent, WM_COMMAND, MAKEWPARAM(nID, BN_CLICKED), hWndButton);
but the lazy version is:
PostMessage(hWndParent, WM_COMMAND, nID, 0);
... assuming the parent doesn't check hWndButton. gotenks got that one.
Assuming we're dealing with a dialog box using standard button IDs, you should use IDOK for nID. Other standard values for nID include IDCANCEL, IDABORT, IDIGNORE, IDYES, IDNO, IDCLOSE. Although, if the ID is custom, it could be any value.
> ::PostMessage(hWnd,WM_LBUTTONDOWN,WM_COMMAND,MAKELONG(x,y));
> //" ::PostMessage(hWnd,WM_LBUTTONDOWN,MK_LBUTTON,MAKELONG(x,y)); "
> also tried.
> ::PostMessage(hWnd,WM_LBUTTONUP,NULL,MAKELONG(x,y));
> ::PostMessage(hWndParent,WM_LBUTTONDOWN,WM_COMMAND,MAKELPARAM(x,y));
> ::PostMessage(hWndParent,WM_LBUTTONUP,WM_COMMAND,MAKELPARAM(x,y));
This'll simulate a button click:
SetForegroundWindow(hWndParent);
PostMessage(hWndButton, WM_LBUTTONDOWN, MK_LBUTTON, MAKELPARAM(1,0));
PostMessage(hWndButton, WM_LBUTTONUP, 0, MAKELPARAM(1,0));
SetForegroundWindow() brings up and activates the window before it handles the mouse click.
Although, if that fails, the button might be off the screen. If that happens, you should call this beforehand:
SetWindowPos(hWndParent, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOZORDER | SWP_SHOWWINDOW);
This'll move the window to the upper-left-hand corner of the screen.
If you're trying to close one certain dialog, then you should have no trouble doing so. But if you're trying to click any given button, chances are that you're gonna run into trouble sooner or later.
Until then, good luck!
Regards
-----------------------Ends-----------------
|
|
|
|
|
Thank You, Vikrant Kpr.
I know SendInput is sloppy, and dangerous when anything can pop up during my sendkeys
and steal input focus. I hadnt been able to make direct Send/PostMessage(s) work.
I presumed that it was because NT security was maybe blocking me.
I *DO* deeply appreciate you showing me how to cast target dialog bits into
my own object-type pointers. I cant wait to try this. This was a problem
I REALLY needed to solve, and it didnt appear anywhere in my many books. And
I didnt find a simple example to mimic from any CodeProject search outputs.
Thanks again.. 8-)
About sending std IDOK/IDCANCEL/IDwhateber messages... My problem (again), is that I
cant find their HWNDs. When I send to the parent window, Once the dialog has
initialized (via DoModal) perhaps, and any queued messages from the main window
get forwarded to the new child dialog, I dont know how to identify it's HWND, nor
its thread. So I cant send it anything.
All of my problem comes down to 'how do I find the main thread's topmost window?'
Can I find a way to enumerate all of ABF's threads, and then enumerate any child
windows of those threads, and then which of those is on top???
And if I can do that, can I send it directed messages (from my foreign application)
((Do I need to attach to the thread first?))
...this is highly tricksy stuff for me... And I dont grok a lot when it comes to
deep windows internals, etc.
Once I get past that last hurdle, I can try out the rest of your suggestions.
Thanks for the reply. Again, it gave me a valuable snippet I was really struggling with.
-Dave
|
|
|
|
|
|
As you know, using CWnd::GetClientRect we can get the dimensions of the client area of a window. Now suppose that we have a toolbar just below the menu bar. this toolbar has occupied a part of the client area! That's if we (e.g.) draw a line from (0, 0) to (100, 100), this line passes across the toolbar !!!  My question is how can I get the client rect, but excluding the toolbar rect.
Thank you masters!
|
|
|
|
|
Well, how about getting the rectangle of the toolbar and then subtracting it from the client rectangle? Something like this:
CRect ClientRect, ToolBarRect;
GetClientRect(ClientRect);
m_MyToolBar.GetWindowRect(ToolBarRect);
ScreenToClient(ToolBarRect);
CRect AvailableRect;
AvailableRect.SubtractRect(&ClientRect, &ToolBarRect);
p.s: am not sure how SubtractRect[^] works, never used it before, so you might need to fiddle with other methods like UnionRect or IntersectRect to get a good result...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Thnx 4 Ur attention. 
|
|
|
|
|
I found this code fragment on t'Net:
CMainFrame *pMainFrame = (CMainFrame *) GetParentFrame();
status bar)
CRect rViewC;
pMainFrame->RepositionBars ( AFX_IDW_CONTROLBAR_FIRST,
AFX_IDW_CONTROLBAR_LAST,
AFX_IDW_PANE_FIRST, CWnd::reposQuery, &rViewC )
It looks about right to me.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I think I've told it to you once; anyway I'me gonna tell one more time: You're a genius ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
Na - I just remember lotsa crap that I can regurgitate (or find with Google) on demand
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: Na - I just remember lotsa crap that I can regurgitate (or find with Google) on demand
Isn't that what being a good programmer is all about? I doubt many of us know everything, we just have a clue where to look, or the search terms.
Iain.
Codeproject MVP for C++, I can't believe it's for my lounge posts...
|
|
|
|
|
Iain Clarke wrote: Isn't that what being a good programmer is all about?
A self-reliant programmer, certainly. The trick is remembering that things actually exist, so you know to look for a solution rather than try to re-invent the wheel.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
