INCONSISTENCY IN VC++ - C / C++ / MFC Discussion Boards

Re: Find control on dialog

Force Code21-May-08 11:37

Force Code

21-May-08 11:37

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?

Re: Find control on dialog

Giorgi Dalakishvili21-May-08 11:50

Giorgi Dalakishvili

21-May-08 11:50

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

Re: Find control on dialog

Force Code21-May-08 12:14

Force Code

21-May-08 12:14

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.

Re: Find control on dialog

Rajesh R Subramanian21-May-08 20:21

Rajesh R Subramanian

21-May-08 20:21

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. Smile | :)

Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP

Re: Find control on dialog

Rajesh R Subramanian21-May-08 19:51

Rajesh R Subramanian

21-May-08 19:51

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;

	// initialize MFC and print and error on failure
	if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
	{
		// TODO: change error code to suit your needs
		_tprintf(_T("Fatal Error: MFC initialization failed\n"));
		nRetCode = 1;
	}
	else
	{
		<font color="brick">HWND hTarget = FindWindowEx((HWND)0x010403CE, //Hard coded handle value 
                                          NULL, //Let the search begin with the first child
                                          _T("Button"), //Class name
                                          _T("OK")); //Window title
		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

Re: Find control on dialog

Giorgi Dalakishvili21-May-08 19:58

Giorgi Dalakishvili

21-May-08 19:58

Thanks

Giorgi Dalakishvili

#region signature
my articles
#endregion

modifying an REOBJECT

Force Code21-May-08 10:00

Force Code

21-May-08 10:00

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);

INCONSISTENCY IN VC++

edu.net21-May-08 9:35

edu.net

21-May-08 9:35

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" // Ensure linker can access mydll.lib and mydll.h

class MyExeClass
{
 public:
  MyExeClass(){}

 public:
  ~MyExeClass(){}

 public:
  VOID MyExeFunc()
  {
    MyDllClass<Someclass> var;  //  Remove DLL_EXPORTS to resolve LNK2019. 
  }
};

Is this behaviour expected? Is it documented?

Love is the illusion that one kiss is different from another. - e.m

Re: INCONSISTENCY IN VC++

JudyL_MD21-May-08 10:02

JudyL_MD

21-May-08 10:02

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

Re: INCONSISTENCY IN VC++

edu.net21-May-08 10:40

edu.net

21-May-08 10:40

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

Re: INCONSISTENCY IN VC++

CPallini21-May-08 10:48

CPallini

21-May-08 10:48

Maybe the inconsistency is in your thoughts:
Do you really think a DLL can export a template class (without specializations)?

See, for instance, here [^].
Smile | :)

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

How to view .lib contents

Jesse Evans21-May-08 7:57

Jesse Evans

21-May-08 7:57

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

Re: How to view .lib contents

CPallini21-May-08 8:13

CPallini

21-May-08 8:13

Have a look at C/C++ Build Tools [^], LIB and DUMPBIN look promising.
Smile | :)

Re: How to view .lib contents

Jesse Evans21-May-08 8:23

Jesse Evans

21-May-08 8:23

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

You're welcome.

CPallini21-May-08 9:39

CPallini

21-May-08 9:39

BTW: I'm not Iain (and neither Alfonso the Wise... Laugh | :laugh:

)

Re: You're welcome.

Hamid_RT21-May-08 17:56

Hamid_RT

21-May-08 17:56

Oh it seems that somebody doesnt like of your reply that you are not Iain. Laugh | :laugh:

Re: You're welcome.

CPallini21-May-08 21:41

CPallini

21-May-08 21:41

Oh I don't bother about down voting: I've a lot of friends Big Grin | :-D

BTW I'm sorry, but no Vivaldi in my (very poor indeed) classical music collection.
Smile | :)

Re: You're welcome.

Hamid_RT21-May-08 23:27

Hamid_RT

21-May-08 23:27

Not problem,thanks. Smile | :)

Re: You're welcome.

ThatsAlok16-Jul-09 20:37

ThatsAlok

16-Jul-09 20:37

Hamid. wrote:
that somebody doesnt like of your reply that you are not Iain

then he can respond to me directly Smile | :)

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture

cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You