C / C++ / MFC Discussion Boards

MKC00221-Sep-11 4:12

21-Sep-11 4:12

This is what i am looking for. I think we should create a window and pass its handle but i am not sure whether it will work or not.
I want to give my own message in UAC window.
Please suggest

Re: ShellExecuteEx for windows7

MKC00223-Sep-11 0:50

MKC002

23-Sep-11 0:50

Hi Is there any example available

Re: ShellExecuteEx for windows7

MKC00225-Sep-11 2:37

MKC002

25-Sep-11 2:37

I have tried below link but could not implement for vc6
Making Your Application UAC Aware[^]

Pointer Casting warning

Software200715-Sep-11 8:57

Software2007

15-Sep-11 8:57

Hi,
while converting C code to C++, I get a casting warning that I can't get rid of
"Warning (Anachronism): Assigning void(*)(int) to extern "C" void(*)(int)"

Anyone? Thanks

C++

#include <signal.h>

struct sigaction sgnl_action;

void handle_alarm() {
    alarm_timededout_=TRUE;
    ...
    }
//In C no warnings
void alarm_manager_(char *typ) {
    if (!strcmp(typ,"init")) {
        void (*func)() = handle_alarm; 
        sgnl_action.sa_handler = func;
        ....
       }

//In C++ 
void alarm_manager_(char *typ) {
    if (!strcmp(typ,"init")) {
        sgnl_action.sa_handler = (void (*)(int))handle_alarm; /////warning on this line
        ....
       }

Re: Pointer Casting warning

David Crow15-Sep-11 9:08

David Crow

15-Sep-11 9:08

What happens with:

void handle_alarm( int )
{
}
...
sgnl_action.sa_handler = handle_alarm;

Re: Pointer Casting warning

Software200715-Sep-11 9:36

Software2007

15-Sep-11 9:36

I get the same exact warning, thats how I had it originally, then I explicitly specified the casting thinking it will get rid of the warning.

It seems to get rid of the warning if I do this, but not sure if its correct functionality?

C++

extern "C" void print(char *)
{
...
}

Re: Pointer Casting warning

krmed15-Sep-11 10:04

krmed

15-Sep-11 10:04

The parentheses you have in

C++

sgnl_action.sa_handler = (void (*)(int))handle_alarm; /////warning on this line

looks strange to me. Perhaps

C++

sgnl_action.sa_handler = (void*)((int)handle_alarm); /////warning on this line

would solve your problem.

Just a guess at the moment - not near my VS to test it.

Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193

Re: Pointer Casting warning

Software200715-Sep-11 10:17

Software2007

15-Sep-11 10:17

This would give an error because the cast is (void(*)(int))(func). Anyways, the complain is about tryiing to cast to an extern "C", when I change my function to an extern "C", it seems to work fine. So, it looks as the signal handler functions have to be standalone external C functions.

Thanks

Re: Pointer Casting warning

Chuck O'Toole15-Sep-11 10:53

Chuck O'Toole

15-Sep-11 10:53

Because the unix / posix libraries work with either C or C++, they all declare their external functions as 'extern "C"' to get the C calling conventions. This is done in the header files, in your case, Signal.h

#ifdef  __cplusplus
extern "C" {
#endif

The field sa_handler needs to point to a function that is declared as "C" callable. Use __cdecl. Note that C calling conventions also affect how the stack arguments are cleaned up so unless you declare the action function correctly, you will end up with stack corruption problems later.

void __cdecl handle_alarm() {
    alarm_timededout_=TRUE;
    ...
    }

Re: Pointer Casting warning

tushar_patil20-Sep-11 20:57

tushar_patil

20-Sep-11 20:57

hi I dnt knw clearly what type of

sgnl_action.sa_handler

is. But this is a little piece of code without any warning and errors might be helpful to you.

#include <stdio.h>


void (*sa_handler)(int);  // function pointer takes int type
                          // arg and retuns void as we have to 
                          //typecast func handle_alarm to this type

void handle_alarm() {
    printf("helooo");
    }

 void  main(int argc, _TCHAR* argv[])
 {
       handle_alarm(); //normal call to function
       sa_handler = (void (*)(int))handle_alarm; // compatible typecast
       sa_handler(0);  // call with a function pointer
                       // as it takes one argument we have 
                       //to pass a dummy arg.
 }

CTreeView classname

_Flaviu15-Sep-11 8:21

_Flaviu

15-Sep-11 8:21

I need to know if focus is on a treeview, and I try it in follow way :

C++

BOOL CMainFrame::IsTreeView(CWnd* pWnd)
{
	ASSERT(pWnd != NULL);

	HWND hWnd = pWnd->GetSafeHwnd();
	if(hWnd == FALSE)return FALSE;

	TCHAR szClassName[10];

	return ::GetClassName(hWnd, szClassName, 10) && _tcsicmp(szClassName, _T("TreeView")) == 0;
}

but didn't work it ... what I've do wrong ? Thanks.

In fact, I need to enable an menu item, if I got focus on a treeview window :

C++

void CMainFrame::OnUpdateEditNewItemMenu(CCmdUI* pCmdUI) 
{
	// TODO: Add your command update UI handler code here

	CWnd* pWnd = GetFocus();
	pCmdUI->Enable(IsTreeView(pWnd));
}

void CMainFrame::OnEditNewItemMenu() 
{
	// TODO: Add your command handler code here
	MessageBox(_T("aaaa"));
}

Re: CTreeView classname

_Flaviu15-Sep-11 9:00

_Flaviu

15-Sep-11 9:00

The answer is in my question Laugh | :laugh:

C++

::GetClassName(hWnd, szClassName, 12);
    TRACE("%s\n",szClassName);

Re: CTreeView classname

etherCao17-Sep-11 12:44

etherCao

17-Sep-11 12:44

In fact, the class name of Tree View is SysTreeView32, it can be found in commctrl.h.

DLL native win32 variables lifetime?

skaboFer15-Sep-11 3:28

skaboFer

15-Sep-11 3:28

Hi, I'm developing a win32 dll, I'm a c# programmer without a lot of experience in c++. Anyway, my dll have to expose a few functions and also has to communicate with a serial port, but my questions is, if one of these functions to expose is like "WriteCommMsg(MsgStr * msg)", I don't know were to declare the necesary variables, for example if I'd have to save the last send msg, were this variable would be declared?, I mean, my doubt is what is the lifetime of the variables in a dynamic win32 dll.

thanks

skabo - Robots are a dynamic work of art...

Re: DLL native win32 variables lifetime?

MicroVirus15-Sep-11 3:57

MicroVirus

15-Sep-11 3:57

The lifetime of static objects for a DLL application is from the Load of your DLL up to the removal (often, program termination) from the executable it is used in.

Some extra information (though not entirely answering your question) can be found here: DllMain entry point[^]. In terms of this article, the static objects live from just before the call with DLL_PROCESS_ATTACH and just until after the call to DLL_PROCESS_DETACH.

Specifically for WriteCommMsg, it looks like the variable (MsgStr) is caller allocated, so you do not need to worry about lifetime of objects there. If msg is used to output data, just write it to the location pointed to. If it is used for input, either use it right away, or save it by copying it to a variable with the appropriate lifetime (probably static in that case).

Easiest way to look at a DLL is as just another executable, except for that it doesn't run stand-alone, but always as part of another executable.

Re: DLL native win32 variables lifetime?

Erudite_Eric15-Sep-11 4:08

Erudite_Eric

15-Sep-11 4:08

skaboFer wrote:
WriteCommMsg(MsgStr * msg)", I don't know were to declare the necesary
variables

The caller would supply the variable, either stack, or heap based, so your dll wont need to worry about it.

skaboFer wrote:
if I'd have to save the last send msg

Then your dll will have to allocate some stack memory and copy the message to it (alloc() or new).

As for lifetime, it is as long as you like with the heap. Remember to free it befoire your dll exits, because if not, you have a memory leak.

You could use static variables, these last the lifetime of the dll in memory.

==============================

Nothing to say.

Re: DLL native win32 variables lifetime?

Richard MacCutchan15-Sep-11 4:17

Richard MacCutchan

15-Sep-11 4:17

skaboFer wrote:
I mean, my doubt is what is the lifetime of the variables in a dynamic win32 dll.

In general the only variables you shaould keep in your DLL are const values that will never change. All non-const variables should belong in your main program and be passed to the DLL routine as required, in the same way as in C#. In your sample function above you define a library function (in the DLL) with the signature

C++

WriteCommMsg(MsgStr * msg)

Here msg is a pointer (reference in C#) to a variable of type MsgStr, but the actual data that msg refers to is stored within the application not the DLL, something like:

C++

MsgStr myMsgString = "message to write"; // setup the message string
WriteCommMsg(&myMsgString);              // send it to the library function

If you wish to keep variable data within your library routines during the lifetime of your application then you should use a static library rather than a DLL.

Unrequited desire is character building. OriginalGriff

Re: DLL native win32 variables lifetime?

skaboFer15-Sep-11 4:35

skaboFer

15-Sep-11 4:35

First of all thanks!

Ok I understand the part of the pointer to the struct that tha main app pass to my function.
But you say that to keep data in my library I should use a static lib instead of a dll, but
could I just declare a static global variable/object?

And what do you think about the object to handle the serial port? where should I declare
the serialPort variable?

Again, thanks for the answers!

skabo - Robots are a dynamic work of art...

Re: DLL native win32 variables lifetime?

Richard MacCutchan15-Sep-11 5:42

Richard MacCutchan

15-Sep-11 5:42

skaboFer wrote:
could I just declare a static global variable/object?

You could but it is generally not considered good form, you should use proper parameter passing between methods in the same way that you would in C#.

skaboFer wrote:
where should I declare

the serialPort variable?

Again declare it in your main application and use the classes or functions in your library to access it without the need to know its actual values. If the code in your DLL becomes specific to the application then there is absolutely no point in creating the DLL in the first place, just put everything in the application.

Unrequited desire is character building. OriginalGriff

Re: DLL native win32 variables lifetime?

skaboFer15-Sep-11 5:53

skaboFer

15-Sep-11 5:53

That's my point...this dll it's not for a especific application, it is a dll based in a norm that only specified the prototypes of the functions that the dll has to have, so then every user application could use it, but the user app doesn´t matter about de serial port...so I have to manage it in my dll...

thanks

skabo - Robots are a dynamic work of art...

Library Usage Problem

AmbiguousName14-Sep-11 23:06

AmbiguousName

14-Sep-11 23:06

hello guys... I have a static library. Now I used this library with another project and compiled both of these. I got plenty of linking error (mostly LNK2001 and LNK2005). I went to both projects' properties and changed

C++

Use of MFC:  Use MFC in Shared DLL

Now question is: since the library is static, should I be using

C++

Use of MFC:  Use MFC in Static Library

? Some tutorial on it is more than welcome. thnx

Re: Library Usage Problem

Erudite_Eric14-Sep-11 23:19

Erudite_Eric

14-Sep-11 23:19

This setting purely affects the way the MFC dlls are used with your applicaiton. They are either linked statically, ie, they are built into the exe (like a .lib file) or they are not, in which case the machine your exe is going to run on had better have the latest MFC dlls installed. (See Microsofts ludicrously named 'side by side' installation for more info on what an utter joke this has become. Yes, with manifests, and versions. Dll hell just became manidest hell...).

Anyway, enough slaging off the people at Microsoft...

Your library is either a dll or a lib.
If it is a lib then you want to use static linking. Make sure the lib is in the link path, and make sure the lib is added to the projects link settings.

If it is a dll you want to use dynamic linking. Even with a dll there is a tiny little lib file, make sure that is in your link path and that it is added to your projects link settings. And deploy the dll with your exe.

==============================

Nothing to say.

modified on Thursday, September 15, 2011 6:12 AM

Re: Library Usage Problem

MicroVirus15-Sep-11 3:47

MicroVirus

15-Sep-11 3:47

For Visual Studio, under the project properties go to the Linker tab. Under general, you can modify the Additional Library directories field if the *.lib file created by your other project is not in a standard directory and not in the same directory as the project. Then under Input, you add the lib file under Additional Dependencies (you probably already see the standard files, such as kernel32.lib, user32.lib, etc. added).

Re: Library Usage Problem

Erudite_Eric15-Sep-11 22:13

Erudite_Eric

15-Sep-11 22:13

Yes, I know. That is what I said to the OP. Smile | :)

==============================

Nothing to say.

Re: Library Usage Problem

Albert Holguin16-Sep-11 3:59

Albert Holguin

16-Sep-11 3:59

I hate it when people reply to me when they meant that for OP. Big Grin | :-D

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.