C / C++ / MFC

How to detect whether a COM port is available or not ?

9-Nov-08 6:21

You're trying to call a function called GetDocument() that doesn't exist
in the context of where you're calling it from.

If you're calling it from within your dialog class code then you need to
implement a method called GetDocument - CDialog doesn't have one.

A few ways to implement this:
Pass a reference to your document into the dialog.
Make the document globally accessible.
Use a CFormView instead of a CDialog. CForm view has a GetDocument().

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

brucewayn8-Nov-08 21:45

brucewayn

8-Nov-08 21:45

I'm working on a GSM application where i'm supposed to send a text msg using AT commands by detecting a com port, however before simulating the comp port i would like to know how we can detect the whether which com port is available.

Re: How to detect whether a COM port is available or not ?

Rolf Kristensen9-Nov-08 1:29

Rolf Kristensen

9-Nov-08 1:29

Serial port enumeration can be done using QueryDosDevice. Here is a wrapper around this interface:

http://www.codeproject.com/KB/system/enumports.aspx (Latest version can be found here
http://www.naughter.com/enumser.html)

To send AT commands to a COM port:

http://www.codeproject.com/KB/system/cserialport.aspx (Latest version can be found here at http://www.naughter.com/serialport.html)

How can I create a working thread in a MFC regular dll

W.Kim 19878-Nov-08 20:51

Re: How can I create a working thread in a MFC regular dll

8-Nov-08 20:51

Hi.
How can I create a working thread in a MFC regular dll and How can I load such a dll in a application?
Smile | :)

Never Change My Goal!

Mark Salsbery9-Nov-08 6:30

Re: How can I create a working thread in a MFC regular dll

9-Nov-08 6:30

First make sure you've covered the requirements for a regular DLL
that uses MFC (taken from the docs):

1) Compiled with _USRDLL defined, and if the DLL links to MFC dynamically,
_AFXDLL must be defined.

2) The DLL must instantiate a CWinApp-derived class.

3) The DLL uses the DllMain provided by MFC. Don't add your own.
Place all DLL-specific initialization code in the InitInstance
member function and termination code in ExitInstance as in a normal
MFC application.

In the dll you can use AfxBeginThread() to create worker threads.

If you don't know how to actually use a DLL, you may want to study:

DLLs[^]

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

W.Kim 19879-Nov-08 14:07

Re: How can I create a working thread in a MFC regular dll

9-Nov-08 14:07

Thanks Mark.
But When I did it as you said,it does not seem to work at all!
can you give me some example code？

Never Change My Goal!

Mark Salsbery9-Nov-08 14:10

Re: How can I create a working thread in a MFC regular dll [modified]

9-Nov-08 14:10

Not working how?

Please list any compiler errors, linker errors, runtime exceptions, etc.

To start with, are you able to successfully call a function in your DLL?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

W.Kim 19879-Nov-08 18:04

Re: How can I create a working thread in a MFC regular dll

9-Nov-08 18:04

there is no compiler errors,linker errors..
the dll loads successfully,and I can call the function in the dll too.

and here is the funtion in the dll:

UINT threadproc(LPVOID lparam)//the thread callback funtion
{
	::MessageBox(NULL,"call the function succeefully","info",MB_OK);
	return 0;
}
extern "C" void __declspec(dllexport) dllext()//the dll export function
{
::MessageBox(NULL,"call the function succeefully in dllext()","info",MB_OK);
CWinThread*pThread=AfxBeginThread(threadproc,NULL,THREAD_PRIORITY_NORMAL,0,CREATE_SUSPENDED ,NULL);
pThread->ResumeThread();
}

and here is the function in a normal MFC application:

void CMainFrame::OnBeginthread() 
{
	//when I click the menu context..the application frame will call this function
	typedef void (*Pdllfun)();
	HINSTANCE hdll=LoadLibrary("thread.dll");
	if(hdll==NULL)
		::MessageBox(NULL,"can not laod the dll","",MB_OK);
	Pdllfun pdllfun=NULL;
	pdllfun=(Pdllfun)::GetProcAddress(hdll,"dllext");
	if(pdllfun==NULL)
		::MessageBox(NULL,"can not laod the dll funion","",MB_OK);
	pdllfun();//call the dll function
	FreeLibrary(hdll);
	
}

if I do not call the pThread->ResumeThread() function which in the dll,everything will be ok.
but once I call the pThread->ResumeThread() function,the main application will crash.
and the errors it returns to me is:

0x00fd102d instruction references "0x00fd102d" memory can not be written

Never Change My Goal!

modified on Monday, November 10, 2008 3:27 AM

Iain Clarke, Warrior Programmer9-Nov-08 22:25

Iain Clarke, Warrior Programmer

9-Nov-08 22:25

The fact that you're using LoadLibrary to load the dll at run time makes a HUGE difference to your question.

In this case, I wouldn't go any near MFC for the DLL at all, just plain vanilla Win32.

I can see one gaping problem though - after you've called resume thread, you return from dllext(), and the promptly call FreeLibrary (). That will (as the name says...) free the library. As you only loaded it once, that will also unload it from your memory. Then windows does a context switch (or could have done at any time - or even simultaneously) to your thread. Which tries to run code that doesn't exist anymore...

Imagine Wile E Coyote running off a cliff, running into mid air for a few seconds, looking down... that's what you've done to your code.

Iain.

Re: How can I create a working thread in a MFC regular dll

W.Kim 198710-Nov-08 3:06

Re: How can I create a working thread in a MFC regular dll

10-Nov-08 3:06

thanks Iain.I have solved the problem.
The fact that you are right!

void CMainFrame::OnBeginthread() 
{
	// TODO: Add your command handler code here
	//when I click the menu context..the application frame will call the function
	typedef void (*Pdllfun)();
	HINSTANCE hdll=LoadLibrary("thread.dll");
	if(hdll==NULL)
		::MessageBox(NULL,"can not laod the dll","",MB_OK);
	Pdllfun pdllfun=NULL;
	pdllfun=(Pdllfun)::GetProcAddress(hdll,"dllext");
		if(pdllfun==NULL)
		::MessageBox(NULL,"can not laod the dll funion","",MB_OK);
		pdllfun();

::MessageBox(NULL,"hold the dll","",MB_OK);//when I add a MessageBox here to let the dll remains in the 
                                            //memory,the problem will not exist any more.

FreeLibrary(hdll);
	
}

so..thanks Iain again!! Smile | :)

Never Change My Goal!

Mark Salsbery10-Nov-08 4:53

Re: How can I create a working thread in a MFC regular dll

10-Nov-08 4:53

Iain Clarke wrote:
Imagine Wile E Coyote running off a cliff, running into mid air for a few seconds, looking down... that's what you've done to your code.

Excellent! Big Grin | :-D

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Mark Salsbery10-Nov-08 5:00

Pointer symbol position and constant member functions

10-Nov-08 5:00

Iain Clarke wrote:
I wouldn't go any near MFC for the DLL at all, just plain vanilla Win32.

If he's truly properly implemented a "regular DLL linked to MFC" as
described here[^]. there should ne no problems.

Probably some thread synchronization issues in the near future for kim_wu...

Thanks for handling the remainder of this thread! Smile | :)

Cheers,
Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Christian Flutcher8-Nov-08 16:55

Re: Pointer symbol position and constant member functions

8-Nov-08 16:55

I got two questions.

1 - Which is the preferred way of using the pointer symbol(*). Is it along with the type or with the identifier?

int* intPtr

OR

int *intPtr;

IMO, the second one is more clear when we declare something like this.

int *intPtr1,intPtr2;

2 - Is it a good practice to append const with member function that doesn't modify any member variables?

int foo::sampleMethod() const{
}

I understand why const member functions exists. But if we are not planning to make the class object as constant, do we need this kind of declarations?

Any help would be great.

Saurabh.Garg8-Nov-08 18:55

Saurabh.Garg

8-Nov-08 18:55

I personally prefer the int* intPtr; But I declare a single variable in a line. This way I can add a comment for each variable I use.

I do add const to each member function that doesn't modify member variables. The problem is you can almost never predict how the class is going to be used at a later time. Once I had to add const to loads of member function for about 10-20 classes. Also, I am not sure, but in certain cases adding const might help compiler to produce more optimized code.

-Saurabh

Re: Pointer symbol position and constant member functions

Christian Flutcher9-Nov-08 5:35

Re: Pointer symbol position and constant member functions

9-Nov-08 5:35

Saurabh.Garg wrote:
But I declare a single variable in a line. This way I can add a comment for each variable I use.

Saurabh.Garg wrote:
The problem is you can almost never predict how the class is going to be used at a later time.

Good points.

Saurabh.Garg wrote:
I am not sure, but in certain cases adding const might help compiler to produce more optimized code.

Do you have any articles/books which explains this?

Thanks for your help

toxcct9-Nov-08 3:05

toxcct

9-Nov-08 3:05

you have an interview, don't you ? Smile | :)

Christian Flutcher wrote:
1 - Which is the preferred way of using the pointer symbol ?

for me, I like to declare every variable separatedly, and I don't like to mix declarations of different types.
this way, I prefer using int* pi; syntax because I see immediately that pi is of type int*.

Christian Flutcher wrote:
2 - Is it a good practice to append const with member function that doesn't modify any member variables?

definitely, yes !
because the one who write the class is not always the one who will use it, a class definition has to be clear, and has to mean what the class is designed for.
When you have an accessor which just does a "get", the it's obviously not modifying the object, and should be declared as const.

Christian Flutcher wrote:
I understand why const member functions exists. But if we are not planning to make the class object as constant,

humm, it seems to me that you don't fully understand the thing.
making a function member constant doesn't mean every function members have to be consts, and it doesn't mean either that the object will be used as a constant.
If you'd like to say that the object is used as a constant, then you would have to do like this :

<font color="blue">class</font> foo { ... };
 
<font color="blue">const</font> foo f(<font color="green">/* some initialization parameters */</font>);

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

Re: Pointer symbol position and constant member functions

Christian Flutcher9-Nov-08 5:30

Re: Pointer symbol position and constant member functions

9-Nov-08 5:30

toxcct wrote:
you have an interview, don't you ?

No I don't have. I just finished reading "Thinking in C++" and about to start a project in C++. So thought of getting some expert advice on those points.

Thanks for you help. It was really helpful.

Iain Clarke, Warrior Programmer9-Nov-08 4:04

Iain Clarke, Warrior Programmer

9-Nov-08 4:04

1/ I normally do:

int *pInt;

2/ the question you ask is why I never mix those. And if the variable it at all significant, it gets its own line. I use long variable names - thanks to intellitext they're just as easy to type, and a lot easier to read. Only loop vars get bunched together. int i,j,k;

3/ I try to use const on member functions that *shouldn't* modify the state, not whether I think I might do so. It gives me the freedom to change my mind in one direction, and makes it harder to code mistakes in the other.

Iain.

Re: Pointer symbol position and constant member functions

Christian Flutcher9-Nov-08 5:32