|
I see. Thanks for your help.
|
|
|
|
|
I can return a passed string with this:
const char *drop(const char *v) { return v; }
But how I can put the passed string into the first index of my array char val[100][50];.
Thanks.
|
|
|
|
|
Hello,
Let's say I have a window created bu external application and I know handle to that window. I need to find control on the dialog with specified class name. So, I know the handle of the dialog which contains the control and I know class name of the control. How can I find it?
One possible way I'm thinking of is enumerating all controls on the form using GetNextWindow and checking control's class using GetClassName function.
Am I on the right track? Is there any better/easier way to do it?
Sorry if my question is stupid, I'm not experienced in Visual c++
Thanks.
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
How about FindWindowEx()?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thanks, I'll try it. As I have practically no experience in win api, I was not sure whether it would find control or not.
Thanks again.
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
Giorgi Dalakishvili wrote: One possible way I'm thinking of is enumerating all controls on the form using GetNextWindow and checking control's class using GetClassName function.
I would use EnumChildWindows and check for the ctrlID for each Child Window using GetDlgCtrlID. The Ctrl ID will be unique and won't change.
Giorgi Dalakishvili wrote: I'm not experienced in Visual c++
Well, it seems you already knew about EnumChildWindows and even how to invoke it from C#:
http://www.codeproject.com/script/Forums/View.aspx?fid=1649&msg=2558300[^]
|
|
|
|
|
Force Code wrote: I would use EnumChildWindows and check for the ctrlID for each Child Window using GetDlgCtrlID. The Ctrl ID will be unique and won't change.
GetDlgCtrlID returns int, how would you check for class name?
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
Giorgi Dalakishvili wrote: GetDlgCtrlID returns int, how would you check for class name?
I assumed you were just trying to locate a specific control, and using the classname for that purpose. If you're just looking for any control of a certain class, then of course you can use GetClassName.
Why would you think to use GetNextWindow as opposed to EnumChildWindows?
|
|
|
|
|
Yes, I'm trying to locate a specific control but I won't know its id in advance, I'll only know its class name.
Force Code wrote: Why would you think to use GetNextWindow as opposed to EnumChildWindows?
I just forgot about EnumChildWindows. Should I prefer it to GetNextWindow? Is there any significant difference between them?
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
Giorgi Dalakishvili wrote: Yes, I'm trying to locate a specific control but I won't know its id in advance, I'll only know its class name.
You can get the control ID with Spy++, or I imagine lots of other utilities as well. If you know enough about the application, then I guess the classname would suffice (also a unique control ID is just convention, and not something that's enforced.)
Giorgi Dalakishvili wrote: I just forgot about EnumChildWindows. Should I prefer it to GetNextWindow? Is there any significant difference between them?
You mentioned it three days ago in the C# thread, and even supplied the msdn link. AS far as differences, to me its just more compact than calling GetWindow or GetNextWindow in a loop. Also, the documentation says,
"[EnumChildWindows] is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed. "
EnumChildWindows does actually return all descendants of a given window and not just immediate children.
|
|
|
|
|
Giorgi Dalakishvili wrote: I just forgot about EnumChildWindows. Should I prefer it to GetNextWindow? Is there any significant difference between them?
In this case, FindWindowEx() should be best for you. Because, you just don't need an enumerated list of all the child windows of the dialog. FindWindowsEx() will just return a handle which pinpoints at the control of your interest. 
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Hi Giorgi,
I chose the Start-->>Run dialog. I then found out the handle of the Run dialog window with Spy++ (You said that you will know it in your case). I am trying to find the OK button with code, using FindWindowEx(). And this small program works for me:
#include "stdafx.h"
#include "CPConsole.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
CWinApp theApp;
using namespace std;
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
_tprintf(_T("Fatal Error: MFC initialization failed\n"));
nRetCode = 1;
}
else
{
<font color="brick">HWND hTarget = FindWindowEx((HWND)0x010403CE,
NULL,
_T("Button"),
_T("OK"));
if(hTarget)
AfxMessageBox(_T("OK button was found"));
else
AfxMessageBox(_T("Unable to find the OK button"));</font>
}
return nRetCode;
}
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Thanks 
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
A rich edit returns an IRichEditOle interface ptr via EM_GETOLEINTERFACE. Then, you can call IRichEditOle::GetObject( LONG n, REOBJECT* reobj, DWORD flags) to retrieve the REOBJECT for some image in the richedit. Does anyone know how to modify that reobject. Specifically I want to change the dwUser field. The following does not work:
REOBJECT reobj = {sizeof(reobj)};
pRichEditOle->GetObject(0,&reobj,REO_GETOBJ_ALL_INTERFACES);
CHARRANGE cr = {reobj.cp,reobj.cp};
SendMessage(hwnd,EM_EXSETSEL,0,(LPARAM)&cr);
reobj.cp = REO_CP_SELECTION;
reobj.dwUser = n;
pRichEditOle->InsertObject(&reobj);
|
|
|
|
|
This is more of an observation than a question.
I have a dll and an exe that uses the dll exports. I export classes from the dll using __declspec(dllexport) (the usual #define SOMENAME that takes care of __declspec(dllexport) and __declspec(dllimport)). I have a template class in the dll. When the class has the __declspec(dllexport)/__declspec(dllimport) attribute, I get a LNK2019 error when i build the exe with all the linker switches appropriately set. I make the class methods inline by implementing them in the header file, still LNK2019. I leave the methods inline and remove the __declspec(dllexport)/__declspec(dllimport) attribute and voila, LNK2019 gone and I can use the class in the exe. I should not be able to use the class in the exe, unless I use one of the export methods, BUT IT WORKS.
I actually reproduced this behaviour and still can't find the docs that say 'DO NOT DECORATE TEMPLATE CLASSES WITH __declspec(dllexport)/__declspec(dllimport) ATTRIBUTE'.
Here's an example:
mydll.h
#ifdef MY_DLL_NAME
#define DLL_EXPORTS __declspec(dllexport)
#else
#define DLL_EXPORTS __declspec(dllimport)
#endif
template<typename T>
class DLL_EXPORTS MyDllClass
{
public:
MyDllClass(){}
public:
~MyDllClass(){}
};
myexe.h
#include "mydll.h"
class MyExeClass
{
public:
MyExeClass(){}
public:
~MyExeClass(){}
public:
VOID MyExeFunc()
{
MyDllClass<Someclass> var;
}
};
Is this behaviour expected? Is it documented?
Love is the illusion that one kiss is different from another. - e.m
|
|
|
|
|
I don't know how to fix your problem with __declspec but the link error goes away when you don't __declspec and do inline because the code now resides in the EXE not in the DLL. The inline has asked the compiler to compile the code into the current compilation unit which is the EXE's source file. The compiler has obviously honored your inline request (it has the option not to). Since the compiled code is now in the EXE (not the DLL), the linker can find it successfully. If you change your DLL implementation, the EXE will not be using the new implementation since it has its own copy of the code compiled into itself.
Judy
|
|
|
|
|
I appreciate your point and totally agree with it, but following the rules, no function or class in a dll (not static library) would be available to any other application or other dll, if ,and unless if, the function or class is exported using either of the two exporting methods available. In my case, the class is not exported but is available to my exe.
Love is the illusion that one kiss is different from another. - e.m
|
|
|
|
|
Maybe the inconsistency is in your thoughts:
Do you really think a DLL can export a template class (without specializations)?
See, for instance, here [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Hi, folks!
I've built a library file, but it does not seems to have all of what I want in it. How can I view what function names are exported from my library?
TIA!
'til next we type...
HAVE FUN!! -- Jesse
|
|
|
|
|
Have a look at C/C++ Build Tools [^], LIB and DUMPBIN look promising.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Iain,
Thanks for the pointers. I figured out what my problem was: it's been too long since i've built a library and I forgot to mark the exportable functions as __declspec(dllexport). My bad!
'til next we type...
HAVE FUN!! -- Jesse
|
|
|
|
|
BTW: I'm not Iain (and neither Alfonso the Wise...  )
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Oh it seems that somebody doesnt like of your reply that you are not Iain.
|
|
|
|
|
Oh I don't bother about down voting: I've a lot of friends 
BTW I'm sorry, but no Vivaldi in my (very poor indeed) classical music collection.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Not problem,thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
