C / C++ / MFC Discussion Boards

Re: ParseCommandLine question

sashoalm8-Sep-08 6:32

sashoalm

8-Sep-08 6:32

I added this code to my InitInstance,

int argc = __argc;
char* arg1 = __argv[0];
char* arg2 = __argv[1];
char* arg3 = __argv[2];
CommandLineParser parser(m_aFileList);
ParseCommandLine(parser);

and the count and the arguments were correctly shown when debugging. But when I step into ParseCommandLine, the arguments are wrong there (they caused an access violation so they must be NULL)! Confused | :confused:

Is this a linker problem? I use MFC as a DLL.

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

David Crow8-Sep-08 6:43

David Crow

8-Sep-08 6:43

So have you tried this instead:

CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);

to eliminate the possibility that your CommandLineParser class is causing problems?

"Love people and use things, not love things and use people." - Unknown

"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

Re: ParseCommandLine question

sashoalm8-Sep-08 6:58

sashoalm

8-Sep-08 6:58

Yes, I've tried, but arguments are still wrong in ParseCommandLine. I think it might be a linker problem. The MFC dll is linked to a different CRT than the exe. Is that possible and can I do something about it?

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

Mark Salsbery8-Sep-08 7:13

Mark Salsbery

8-Sep-08 7:13

sashoalm wrote:
The MFC dll is linked to a different CRT than the exe.

I hope you know what you're doing there. Smile | :)

For more info on what you can/can't do with MFC DLLs:
Kinds of DLLs[^]

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

Re: ParseCommandLine question

sashoalm8-Sep-08 7:18

sashoalm

8-Sep-08 7:18

No problem there. We're using vc6 with mfc 4.2. You'd have to be running Windows 3.1 not to have the dlls Big Grin | :-D

(ok Windows 95)

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

Mark Salsbery8-Sep-08 7:23

Mark Salsbery

8-Sep-08 7:23

I have no idea what you're talking about. Smile | :)

I'm talking about mixing CRT libraries between DLLs and EXEs.

I'm not sure what a DLL has to do with this anyway, unless your InitInstance
is in the DLL, in which case the commandline stuff will probably fail
if the DLL is using a different CRT.

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

Re: ParseCommandLine question

sashoalm8-Sep-08 7:53

sashoalm

8-Sep-08 7:53

Mark Salsbery wrote:
I have no idea what you're talking about.

I thought you were talking about having to redistribute the MFC DLLs.

Sorry about the misunderstanding. I've written in my earlier post 'The MFC dll is linked to a different CRT than the exe'. I meant 'The MFC dll might be linked' and the error might come because of this. Otherwise why would it be correct in my InitInstance, then stop being correct when I step into ParseCommandLine?

I was thinking that there are two copies of __argc and __argv, one for the EXE and one for the MFC DLLs, and ParseCommandLine looks at a different variable. I've had a similar problem when I used a static variable in a function that was inside the class body. I had the variable correctly initialized in one cpp file, then when the function was called from another cpp file, the variable was uninitialized. I found out that I didn't have a single static variable, instead I had a different static variable for each cpp file where the function was invoked.

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

Mark Salsbery8-Sep-08 7:59

Mark Salsbery

8-Sep-08 7:59

sashoalm wrote:
I was thinking that there are two copies of __argc and __argv, one for the EXE and one for the MFC DLLs

Yes, if the DLL is linked to a different CRT than the EXE.

That's why I stated I hope you know what you're doing there Smile | :)

If you mix different versions of MFC and/or the CRT in one process,
then you need to make sure you know what's going on - for example, you can't
allocate an object using "new" in A DLL and try to delete the object in
the EXE if they are using different CRTs. Also you need to be sure initialization
of MFC and the CRT are done properly in the DLL.

The link in my first reply describes those scenarios so you can mix MFC/CRT
properly.

Mark

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

Re: ParseCommandLine question

sashoalm8-Sep-08 8:56

sashoalm

8-Sep-08 8:56

I copy/pasted the code of ParseCommandLine in my own CWinApp-derived class, and now it works fine. It seems that the __argc visible from my code and the __argc visible from APPCORE.CPP are two different variables, but I'm still not sure if I have different CRTs. My project is not a dll, and using MFC as a shared DLL is the default in AppWizard. The only thing I've tweaked is setting the CRT to multithreaded dll instead of singlethreaded. Do you have any suggestions how to find out if I have different CRTs? That would be very helpful.

As for the different variables, actually the __argc visible from APPCORE.CPP is a mess of macros and function pointers, and the __argc visible from my code is a variable. Here's the code in MFC about __argc/__argv

#if     defined(_DLL) && defined(_M_IX86)

#define __argc      (*__p___argc())     /* count of cmd line args */
#define __argv      (*__p___argv())     /* pointer to table of cmd line args */
_CRTIMP int *          __cdecl __p___argc(void);
_CRTIMP char ***       __cdecl __p___argv(void);

#else

_CRTIMP extern int __argc;          /* count of cmd line args */
_CRTIMP extern char ** __argv;      /* pointer to table of cmd line args */

#endif

/*
 * Functions to access user-visible, per-process variables
 */

/*
 * Macro to construct the name of the access function from the variable
 * name.
 */
#define AFNAME(var) __p_ ## var

/*
 * Macro to construct the access function's return value from the variable
 * name.
 */
#define AFRET(var)  &var

_CRTIMP int * __cdecl
AFNAME(__argc) (void)
{
        return AFRET(__argc);
}

/*
 * Macro to construct the access function's return value from the variable
 * name.
 */
#define AFRET(var)  &var

It looks very complicated.

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

Mark Salsbery8-Sep-08 9:15

Mark Salsbery

8-Sep-08 9:15

sashoalm wrote:
My project is not a dll, and using MFC as a shared DLL is the default in AppWizard. The only thing I've tweaked is setting the CRT to multithreaded dll instead of singlethreaded.

Are you mixing a non-debug multithread CRT DLL with the
debug version of MFC? If so, then there would be two CRTs.

You need to make sure you're using the same CRT library as the
MFC library is using.

You can see what DLLs are loaded int the output window when you run
in the debugger.

Mark

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

Re: ParseCommandLine question

sashoalm8-Sep-08 21:43

sashoalm

8-Sep-08 21:43

I found a flag in my linker options - /nodefaultlib:"msvcrtd.lib", after removing it CWinApp::ParseCommandLine works.

But the linker now gives me a warning:

LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library

Is this warning a problem?

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

Mark Salsbery9-Sep-08 5:06

Mark Salsbery

9-Sep-08 5:06

I imagine you're linking a library which is trying to link a
different CRT version.

All warnings are problems IMO.

If it were me, I'd definitely track it down and try to fix it.

If you use the app wizard to create a temporary MFC project,
you'll get a good default set of settings. Compare those to yours...

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

Re: ParseCommandLine question

Matthew Faithfull8-Sep-08 5:11

Matthew Faithfull

8-Sep-08 5:11

I'm not sure what the cause is exactly but I may be able to offer some help finding it. Clearly you're using MFC and ParseCommandLine is going to be relying on the MFC startup code to provide it with the command line data. This in turn will be getting the data from the C Runtime startup code which runs before MFC gets started. This code in turn gets the command line arguments from the Windows Portable Executable Loader which gets them from the actual 'command line' via Windows itself.
Somewhere a link in this chain has broken and no command line parameters have been stored or passed on to the next stage.
I would start by tracking back the C Runtime startup code to a point where the command line is available e.g. __mainCRTStartup and then track it forward to find where the broken link is. I strongly suspect it will be between the C Runtime and MFC, probably because you need to call some MFC startup code that you aren't calling before calling ParseCommandLine.

"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)

Re: ParseCommandLine question

sashoalm8-Sep-08 5:24

sashoalm

8-Sep-08 5:24

Matthew Faithfull wrote:
Somewhere a link in this chain has broken and no command line parameters have been stored or passed on to the next stage

But CWinApp::m_lpCmdLine shows the command line I give correctly. Could it be that ParseCommandLine tries to get it's params from a different avenue?

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: ParseCommandLine question

Matthew Faithfull8-Sep-08 5:46

Matthew Faithfull

8-Sep-08 5:46

Yes, it looks like it might be going back to the CRT which may have had its copies deleted for some reason by this stage. If MFC has the data you want then as a last resort you could simply write/override your own function to access it.

"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)

Changing the text color in the combobox dynamically

hariakuthota8-Sep-08 3:56

hariakuthota

8-Sep-08 3:56

Hi all i am new to vc++.
In my application i want to change the textcolor in the combobox dynamically is there a way by which i can do this????
Thanks in advance...

Re: Changing the text color in the combobox dynamically

enhzflep8-Sep-08 17:14

enhzflep

8-Sep-08 17:14

Yeah sure there is, though if the control exists on a dialog you have more limited options when it comes to easily colouring the background.

If the control exists on a dialog, you may have the following code inside your DialogProc

case WM_CTLCOLORLISTBOX:
    SetTextColor((HDC)wParam, RGB(250, 100, 0));   // an orange colour
    return TRUE;                                   // message handled

If the control exists on a normal window, you can return a handle to the brush used to draw the background.

case WM_CTLCOLORLISTBOX:
    SetTextColor((HDC)wParam, RGB(250, 100, 0));   // an orange colour
    return GetStockObject(LTGRAY_BRUSH);           // hbrush to use for background

on receipt of the message, lParam = the HWND of the list box. You may want to check the value of this param if you have more than one list/combo box and you'd like them to have different colours.

MFC Datetime to String

mehmetned8-Sep-08 3:29

mehmetned

8-Sep-08 3:29

How can i convert MFC datetime to MFC string? Thank you.

Re: MFC Datetime to String

toxcct8-Sep-08 3:42

toxcct

8-Sep-08 3:42

what about using COleDateTime::Format()[^] ?

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

viewing pictures in tif format using CImage

susanne18-Sep-08 2:24

susanne1

8-Sep-08 2:24

Hi everybody, need to view pictures that have tif format, by using CImage class.Any idea will be appriciated. Thanks.

Re: viewing pictures in tif format using CImage

SandipG 8-Sep-08 2:53

SandipG

8-Sep-08 2:53

Documentation says
CImage Class
CImage provides enhanced bitmap support, including the ability to load and save images in JPEG, GIF, BMP, and Portable Network Graphics (PNG) formats.

I cant see TIFF in the list Smile | :)