|
GetClassName
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Hey there,
I have an application which has a "ThunderRT6UserControlDC". There are various control within this container such as
1. A drop down box
2. Label box
3. Gifs
4. a List View
For some reason 1 and 2 are not visible as having handles when viewed from Spy++.
I need to get the handle to the Label box (2) to retrieve its text. I'm trying to access this from a different program so I have to use handles and cannot use properties withing my application.
Any suggestions!!
Abhishek
|
|
|
|
|
Abhishek Karnik wrote:
For some reason 1 and 2 are not visible as having handles when viewed from Spy++.
Are they obscured by some other control like a groupbox?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hey David,
I'm not sure ..... the ThunderRT6UserControlDC is a child of ThunderRT6PictureBoxDC which contains a number of ThunderRT6UserControlDC's. However I don't think its obscured. If it were it would have shown up in Spy++ ( is assume).
regards
Abhishek
|
|
|
|
|
Abhishek Karnik wrote:
Hey there,
I have an application which has a "ThunderRT6UserControlDC". There are various control within this container such as
1. A drop down box
2. Label box
3. Gifs
4. a List View
For some reason 1 and 2 are not visible as having handles when viewed from Spy++.
One possible reason for those controls not appearing in Spy++ is that they might not be separate windows. The drawing and behavior of those controls might be implemented directly inside ThunderRT6UserControlDC.
Is that a VB app? I seem to remember reading somewhere that VB implement some basic controls entirely by its own without creating actual Win32 windows for them. That would explain what you are seeing (and what not) in Spy++...
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
hey Jose,
If they are implemented directly inside ThunderRT6UserControlDC, do you think there is some way of extracting the text.....using a Gettext or something.......because I am not sure if that would work since the there seem to be subcomponents with different structures (like the drop down compared to a text box)
Jose Lamas Rios wrote:
Is that a VB app?
Yes the application that I am targetting is a VB application...I'm sriting my code in VC.
|
|
|
|
|
Abhishek Karnik wrote:
If they are implemented directly inside ThunderRT6UserControlDC, do you think there is some way of extracting the text.....using a Gettext or something
No, if that is the case, I don't think there is a way to get the text.
But maybe you can find something googling for ThunderRT6UserControlDC or asking in a VB forum...
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Hey all
Ive created a API modeless dialog inside of a DLL, and is created whenever the calling program calls the appropriate exported function. In a past thread that i posted, this dialog would cause the application to lock up with the not responding dialog. Thanks to someones tip to use DefWindowProc() I can now get the dialog to work (pops up, and close button properly closes when clicked), only it appears to not be responding to move messages (the message called when i would like to drag the dialog around on the screen).
From DLLMain:
<br />
hDLL = hinstDLL;<br />
The exported function that starts the dialog:
<br />
<br />
<br />
int __stdcall WINAPI x(HWND mWnd, HWND aWnd, char *data, char *params, BOOL show, BOOL nopause){<br />
<br />
MSG msg;<br />
<br />
hDlg = CreateDialog(hDLL, MAKEINTRESOURCE(IDD_DIALOG1), mWnd, (DLGPROC)DlgCallBack);<br />
<br />
ShowWindow(hDlg,SW_SHOW);<br />
<br />
while (GetMessage(&msg, NULL, 0,0)) {<br />
TranslateMessage(&msg);<br />
DispatchMessage(&msg);<br />
}<br />
}<br />
The DLGPROC:
<br />
LRESULT CALLBACK x(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam){<br />
switch (uMsg) <br />
{ <br />
case WM_COMMAND:<br />
<br />
switch(wParam){<br />
case IDOK:<br />
DestroyWindow(hDlg);<br />
return TRUE;<br />
}<br />
<br />
break;<br />
<br />
case WM_DESTROY: <br />
DestroyWindow(hDlg);<br />
PostQuitMessage(0);<br />
return TRUE;<br />
}<br />
<br />
return DefWindowProc(hwnd, uMsg, wParam, lParam);<br />
}<br />
|
|
|
|
|
KnaveR wrote:
while (GetMessage(&msg, NULL, 0,0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Shouldn't this be:
while (GetMessage(&msg, NULL, 0,0))
{
if (! IsWindow(hDlg) || ! IsDialogMessage(hDlg, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thnx for this suggestion, I was wondering how GetMessage could could possibly be knowing that the msg was for my dialog... this answered that. However, I am still unable to move the dialog, any suggestions?
|
|
|
|
|
Maybe you should try patching up your switch for WM_COMMAND, considering this note in MSDN:
The WM_COMMAND message is sent when the user selects a command item from a menu, when a control sends a notification message to its parent window, or when an accelerator keystroke is translated.
wParam
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
You completely switched on wParam instead of breaking out the hiword and loword 
switch( LOWORD(wParam) ){<br />
case IDOK:<br />
DestroyWindow(hDlg);<br />
return TRUE;<br />
}
|
|
|
|
|
Thnx for pointing that out, but it seems something else might be amiss. I just tried putting my "return DefWindowProc(hwnd, uMsg, wParam, lParam);" statement at the top so that all messages would be handled by the default window proc, thinking that this would allow my dialog to perform basic dragable behavior, but it is still not budging.
One other thing i noticed is that if i use my hDlg, which i get from CreateDialog(), inside the DefWindowProc an exception is thrown. Am I wrong in thinking that this should work, as hDlg works with calls to DestroyWindow?
I also would like to thank you all for your help, I have spent many days trying to track down what I am doing wrong.
|
|
|
|
|
KnaveR wrote:
return DefWindowProc(hwnd, uMsg, wParam, lParam);
Shouldn't this be return DefDlgProc(hwnd, uMsg, wParam, lParam); instead?
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
DefDlgProc will cause infinite recursion if i use it 
|
|
|
|
|
Given this note in MSDN in relation to possessing a DialogProc:
You should use the dialog box procedure only if you use the dialog box class for the dialog box. This is the default class and is used when no explicit class is specified in the dialog box template. Although the dialog box procedure is similar to a window procedure, it must not call the DefWindowProc function to process unwanted messages. Unwanted messages are processed internally by the dialog box window procedure.
Have you just tried returning FALSE instead of other processing, as per this note:
Typically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
Maybe with the improved handler (using the IsDialogMessage) you don't need to call DefWindowProc.
Also, there is this note:
If the dialog box procedure processes a message that requires a specific return value, the dialog box procedure should set the desired return value by calling SetWindowLong(hwndDlg, DWL_MSGRESULT, lResult) immediately before returning TRUE. Note that you must call SetWindowLong immediately before returning TRUE; doing so earlier may result in the DWL_MSGRESULT value being overwritten by a nested dialog box message.
|
|
|
|
|
You are Da Man!!! A million thnx!!!
Have you just tried returning FALSE instead of other processing, as per this note... Maybe with the improved handler (using the IsDialogMessage) you don't need to call DefWindowProc.
Originally I was returning FALSE, but was not using IsDialogMessage. Hope that this helps someone in the future.
|
|
|
|
|
Dear group,
I am using the IHTMLCurrentStyle class (Visual C++) from the IE's API to get the colour of elements on webpages. I am using the method: HRESULT IHTMLCurrentStyle::get_color(VARIANT *p);
It works perfectly fine. As you might know i would need to do hexadecimal to RGB conversion. but the problem is that people sometimes encode colour as names instead of hexadecimal representation (red instead of #ff0000).
This makes life harder for me because i will need to convert colours from actual names to hexadecimal representations then to RGB format
Does anyone know any method which directly extracts colours in RGB formats ? or at least have any idea on how to perform this efficiently ?
Any ideas are welcomed
llp00na
|
|
|
|
|
|
Thanx for the reply Chris
I am afraid that doesn help alot, because i would need to perform some operations on the colours i extract.
therefore, i need the colours in RBG format, not in hex or string name formats.
llp00na
|
|
|
|
|
|
I understand what you suggested, but the problem is that web builders do not always use (names) to refer to colours. they most of times use hex format, normal formats such as #ffffff would be easy to convert to RGB representation. however, I have encountered some special cases where designers use #fff to refer to #0f0f0f !!!
llp00na
|
|
|
|
|
llp00na wrote:
I have encountered some special cases where designers use #fff to refer to #0f0f0f !!!
But did it work, or did it just default to black? When HTML encounters an invalid color, does it approximate or fail over to some color that's known to exist?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
llp00na wrote:
however, I have encountered some special cases where designers use #fff to refer to #0f0f0f !!!
But did it work, or did it appear to work because the browser either approximated a color, or just failed over to a color that's known to exist?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hii all
i am getting a single error when i complile my project
the error is::
c:\program files\microsoft visual studio\vc98\mfc\include\afxv_w32.h(14) : fatal error C1189: #error : WINDOWS.H already included. MFC apps must not #include <windows.h>
how to solve this error??????
thanks a lot
|
|
|
|
|
So are you including windows.h like the error indicates?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
