C / C++ / MFC

Re: How can i chang the type of int to type of POSITION

24-Aug-05 10:23

DavidCrow wrote:
All valid points, but they still fail to explain why "MFC is crap."

The MFC *containers* are crap. For the reasons I have stated.

DavidCrow wrote:
Are you assuming that the non-MFC application is still GUI? If

No, why would I ?

DavidCrow wrote:
If so, I'm not sure how the STL would be of any help to someone wanting to create a GUI application. If not, then the STL would certainly be of value.

You seem to have missed my point. If I am working on a nonMFC app, and I need containers, if I have learned the MFC ones instead of STL ( as many do ), I will be initially lost.

DavidCrow wrote:
How is it better supported? Are you talking about support from Microsoft?

No, I'm talking about compilers that support the STL, compared to compilers that support MFC.

DavidCrow wrote:
All tools have limitations. Those limitations, however, are not always relevant to the solution.

Yes, I agree. MFC in general has limitations, but I still regard it as a good library, certainly a good alternative to Win32. However, like I said, it does include stuff that IMO does not add to the library, and encourages bad programming practice. The MFC containers were written prior to the C++ standard, and exist for legacy support. I'm aware of shops that don't let programmers use STL because 'Microsoft has containers and we're a Microsoft shop'. That sort of idiocy, combined with general ignorance ( that is, people using MFC find the containers, and have no idea there is a standard alternative ), is the reason I remain a pariah, a lone preacher in the wilderness, defending the use of the standard library for containers.

Christian Graus - Microsoft MVP - C++

David Crow24-Aug-05 10:40

David Crow

24-Aug-05 10:40

Christian Graus wrote:
The MFC *containers* are crap.

My bad. I overlooked the 'containers' part.

Christian Graus wrote:
If I am working on a nonMFC app, and I need containers, if I have learned the MFC ones instead of STL ( as many do ), I will be initially lost.

Why? That implies that those who do not know/use STL are lost. Can such a generalization be made?

Christian Graus wrote:
No, I'm talking about compilers that support the STL, compared to compilers that support MFC.

Ok, but what if support for more than one compiler is not one of the requirements? Is that still a reason to use one over the other?

Christian Graus wrote:
However, like I said, it...encourages bad programming practice.

For example.

"One must learn from the bite of the fire to leave it alone." - Native American Proverb

Re: How can i chang the type of int to type of POSITION

Christian Graus24-Aug-05 10:52

Re: How can i chang the type of int to type of POSITION

24-Aug-05 10:52

DavidCrow wrote:
Why? That implies that those who do not know/use STL are lost. Can such a generalization be made?

Because I'm sure a LOT of people who use the MFC containers don't even know they are part of MFC. If I am used to using a language, and suddenly the part I try to use goes AWOL, I will be confused, and I'll need to find/learn an alternative. That's all I meant by 'lost'.

DavidCrow wrote:
Ok, but what if support for more than one compiler is not one of the requirements? Is that still a reason to use one over the other?

Yes, for the reasons I stated. Apart from the STL containers being *better*, they are also cross platform, you lose NOTHING by learning how to use them, and if you find yourself on a project that is on another platform, you'll already know how to use the containers there.

DavidCrow wrote:
For example.

It is bad practice IMO to tie yourself to a specific platform, which is not even universal in the Windows world, let alone the programming world at large, when the standard alternative is actually better. Microsoft did not intend for people to do this, either. Just like it's bad practice to pass char * around instead of using a string class, or FILE handles instead of a stream class, but people do it, because it's what they are used to, and they never stop to think of alternatives.

Christian Graus - Microsoft MVP - C++

MailtoGops22-Aug-05 22:34

MailtoGops

22-Aug-05 22:34

Do not use indexers to locate item in the list..

You can use Position..

Use the following code

POSITION Pos = str.list.GetHeadPosition();

while (Pos != NULL)
{
this->lst.AddTail(str.list.GetNext(pos));
}

" Action without vision is only passing time,
Vision without action is merely day dreaming,
But vision with action can change the world "

- Words from Nelson Mandela

Thanks & Regards,

Gopalakrishnan

DirectShow output buffer issue

sashi_ua22-Aug-05 14:07

sashi_ua

22-Aug-05 14:07

Hello,
I am trying to build a small directshow application as follows:

video-capture-source --> MPEG2 demultiplexer --> MainConcept MPEG Decoder --> video renderer.

This I have done successfully. However, now I just want to tap the output of the MPEG decoder (frame by frame without saving into hard disk) and do some post processing on these frames. Can anyone suggest me how to do this. mind you, that i dont want to save it on a hard disk using file writer, i just want to capture the output frame by frame -process each frame and provide a score or something like that as output.

Thanks,
Sashi.

More linker errors

Christian Graus22-Aug-05 13:33

22-Aug-05 13:33

I am now trying to compile a DICOM toolkit ( public domain ) that comes with a VS2003 project, but does not compile. The errors are all in linking, stuff like

Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir

Now: if I go to the project settings, the command line generated is this :

/Od /I "../../config\include" /I "../../dcmjpeg\include" /I "../../ofstd\include" /I "../../dcmdata\include" /I "../../dcmimgle\include" /I "../../dcmimage\include" /I "../../dcmjpeg\libijg8" /I "../../dcmjpeg\libijg12" /I "../../dcmjpeg\libijg16" /I "../../../zlib-1.2.1\include" /I "../../../tiff-3.6.1\include" /I "../../../libpng-1.2.5\include" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_REENTRANT" /D "WITH_LIBPNG" /D "WITH_LIBTIFF" /D "WITH_ZLIB" /D "dcmmkdir_EXPORTS" /D "CMAKE_INTDIR=\"Debug\"" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /FD /EHsc /RTC1 /MTd /Fp".\Debug/dcmmkdir.pch" /Fo".\Debug\\" /Fd".\Debug\\" /W3 /nologo /c /Z7 /TP /errorReport:prompt

I think this bit: /D "CMAKE_INTDIR=\"Debug\"" is the problem, but I can't see where it's set, there are places that set the directory to build to be debug, but none have the trailing quote. Can anyone suggest how I fix this ?

Christian Graus - Microsoft MVP - C++

Jose Lamas Rios22-Aug-05 16:53

22-Aug-05 16:53

Christian Graus wrote:
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir
Now: if I go to the project settings, the command line generated is this :
/Od /I "../../config\include" /I "../../dcmjpeg\include"

That's the command line for the compiler, not the linker

Christian Graus wrote:
I think this bit: /D "CMAKE_INTDIR=\"Debug\"" is the problem, but I can't see where it's set

It should be under C/C++ / Preprocessor / Preprocessor Definitions.

Christian Graus wrote:
there are places that set the directory to build to be debug, but none have the trailing quote

If you look at the Preprocessor Definitions you should find one saying

CMAKE_INTDIR=\"Debug\"

That is, with escaped quotes. When the definition is passed to the command line, it's in turn surrounded by quotes and appended after a /D option. So, the quotes (both escaped and normal) are properly balanced. I don't think that would be a problem.

I'd look at the linker command line

Christian Graus wrote:
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir

That's what you see in the "Error List" or "Task List" tab, right? If I interpret it right, dcmmkdir is just the name of the project in which the error occurred and not part of the error message itself, which is in another column. If I got it right, then, the actual error is saying there is a syntax error in option '' (note it's not a quote, but actually an empty option surrounded by single quotes)... That's odd...

Look at the wording in the Output window, which will show the exact output from the linker. Maybe that would shed some light and point you in the right direction.

--
jlr
http://jlamas.blogspot.com/[^]

Christian Graus22-Aug-05 18:20

22-Aug-05 18:20

Doh !!! I didn't have the output window visible.

This is what I get for one of them:

LINK : fatal error LNK1117: syntax error in option ''
Project : warning PRJ0018 : The following environment variables were not found:
$(INT /LIBPATH:../../dcmimgle\$(INTDIR)

I'm finding that the link extra commands is perhaps too long, I'm replacing it with explicit paths to any lib files it reports it needs, that seems to be going OK, so far.

Christian Graus - Microsoft MVP - C++

Jose Lamas Rios22-Aug-05 19:30

22-Aug-05 19:30

Christian Graus wrote:
$(INT /LIBPATH:../../dcmimgle\$(INTDIR)

That looks like an incomple $(INTDIR) macro, which stands for Intermediate Directory. That macro is used for "Debug" or "Release" depending on the configuration you are building. It seems like since the macro got truncated (i.e.: $(INT instead of $(INTDIR) ), the linker kept looking for the closing parenthesis and interpreted all that (including the next libpath) as a macro, which then of course couldn't find.

Look for $(INT followed by a blank space in Linker / Command line / Additional options or in Linker / General / Additional Library Directories, and complete the macro. That should work.

--
jlr
http://jlamas.blogspot.com/[^]

Christian Graus22-Aug-05 19:36

22-Aug-05 19:36

I don't think any of these are mangled, I've been looking at them all day. It seems more likely that they are being truncated, because the list is so long. At least, some info I found on the web suggests this to be the case. I'm abandoning this list, and adding paths to the additional include directories for each file, which has worked for 2 of the 5 projects so far ( I've been sidetracked from doing the rest ).

Thanks for your help.

Christian Graus - Microsoft MVP - C++

Jose Lamas Rios22-Aug-05 20:06

22-Aug-05 20:06

I was curious so I downloaded and opened this project with VS2005 (don't have VS2003 in this machine) and the options are definitively mangled.

There are around 270 options, most of which are duplicated (each libpath is repeated around 7 or 8 times). Besides that, I found:

3 cases of a single slash with nothing else. That would explain that LNK1117 with an empty option in your first post.

One option saying:
/LIBPATH:../../../zlib-1.2.1\lib\$(INT
and followed by:
/LIBPATH:../../dcmimgle\$(INTDIR)

That's the last error you post.

One option saying:
/LIBP
which is probably an error too.

One option saying:
/LIBPATH:../../../ti
which is probably a truncated version of
/LIBPATH:../../../tiff-3.6.1\lib\

One option saying:
/LIBPATH:../../d
which is probably a truncated version of
/LIBPATH:../../dcmdata\
or any of the other paths starting with 'd'

And many others that seem similarly truncated.

All these problems may be related to errors in the conversion from a VC6 project to VS2003/2005.

Did you use the CMake utility as indicated by the instructions in the Install file? If I understood it right, that's the proper way to convert it to VS2003.

--
jlr
http://jlamas.blogspot.com/[^]

Christian Graus23-Aug-05 13:14

23-Aug-05 13:14

No, I found the instructions about CMake, but initially I just saw a VS2003 project and expected it to work. Why would they have a broken project file in there, I don't get it ?

Anyhow, I've nearly got it building, if I have more trouble with it, I'll go back to CMake. The reason for this is that this library links into the project that I've moved to VC2005, and I get a lot of basic_ostream linking errors on this library, so I need to be able to compile it to figure out the problem and fix it.

Christian Graus - Microsoft MVP - C++

ClistCtrl question

Tom Wright22-Aug-05 12:54

Tom Wright

22-Aug-05 12:54

I've got a list control that I'm using for different profiles in my app. When I add a profile to the control it lists it correctly. However when I delete a profile I cannot get the control to move up the icons so that they are taking up the space. Is there a way to move the icons up without reloading the list control?

Thanks

Tom Wright
tawright915@yahoo.com

Re: ClistCtrl question

Jose Lamas Rios22-Aug-05 17:02

Trouble passing a class pointer to AfxBeingThread

22-Aug-05 17:02

Tom Wright wrote:
Is there a way to move the icons up

I'm not sure if I got your question right, but maybe you are looking for this method:

CListCtrl::Arrange[^]

Or you might use the LVS_AUTOARRANGE style.

--
jlr
http://jlamas.blogspot.com/[^]

Re: ClistCtrl question

Tom Wright23-Aug-05 4:57

Tom Wright

23-Aug-05 4:57

Thanks that did it.

Tom Wright
tawright915@yahoo.com

KnaveR77722-Aug-05 12:49

KnaveR777

22-Aug-05 12:49

Hey all, Im having a problem with passing a var to a function via AfxBeginThread. It appears the function is being called properly, but my data, which is in the form of a pointer to one of my ServerData classes, appears corrupted in the eyes of the thread function (debugger shows data as it should be before call, inside thread function, everything is chaotic).

This is the code the starts the thread (triggered by a CListView message):

<br />
LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]); <br />
ServerData* sdat = (ServerData*)ptr;  // debugger shows sdat to be intact<br />
<br />
CWinThread* thread = AfxBeginThread(&queryServer, ptr);<br />

This is performed at the begining of my thread func:

<br />
UINT queryServer(LPVOID pParam ){<br />
ServerData* server = ((ServerData*)pParam);  // the var server has bad data<br />
<br />
...<br />
}<br />

ServerData's LPVOID cast operator is simply defined as:

<br />
return this;<br />

Any ideas?

Re: Trouble passing a class pointer to AfxBeingThread

MailtoGops22-Aug-05 23:00

MailtoGops

22-Aug-05 23:00

Hi KnaveD,

I would like to interpret the following your statement..

LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]);

I can assume that m_serversList[pNMIA->iItem] returns the ServerData object from an array of m_serversList. If you look at your typecasting, it seems to be, it is returning a temporary object, which you are typecasting to a void. That object is not at all a pointer!!!!

Solution
---------

If I am not wrong, you can modify your code like this..

LPVOID ptr = (LPVOID)((ServerData*) &m_serversList[pNMIA->iItem]);

ie to get the address of the array element..

" Action without vision is only passing time,
Vision without action is merely day dreaming,
But vision with action can change the world "

- Words from Nelson Mandela

Thanks & Regards,

Gopalakrishnan

Q about WINDBG

valerie9922-Aug-05 12:41

valerie99

22-Aug-05 12:41

Hi, all

I have installed the WINDBG and trying to use it for VC6, my question is how to open up and memory dump in VC6 and attach to the source code? could it be done for VC98?

The reason I am trying this is the release version of application crashed on one testing box with "application error" and not happening on my side.....so I installed the WINDBG in test box and created the memory dump.....

any info will be greatly appreciated.

Re: Q about WINDBG

Blake Miller23-Aug-05 4:28

Blake Miller

23-Aug-05 4:28

You are probably better off to open the memory dump in the WINDBG.
WINDBG makes a 'fuller' memory dump than the VC6 can understand.

If you fill in the WINDBG folders for symbols and source files, it will lead you to exactly the source file and line where the crash occurred, based upon the information in the DMP file.

Open the DMP file first.
Set the 'symbols' path to point to your PDB files that EACTLY match the release build the customer has.
Set the path leading to your source files.
Issue a .reload in the WINDBG command window.
Execute a 'g' command to 'go' and it will lead you to the crash.

How to use the WIN32API in MFC Application??

shanzy22-Aug-05 12:03

shanzy

22-Aug-05 12:03

BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
m_pMainWnd->ShowWindow(m_nCmdShow);
m_pMainWnd->UpdateWindow();

return TRUE;
}

I change it to the next code block,but I got some error

BOOL CMyApp::InitInstance()
{
m_pMainWnd = new CMyFrameWnd;
::ShowWindow(hWnd,m_nCmdShow);
::UpdateWindow(hWnd);

return TRUE;
}

Is there any WIN32API can change "m_pMainWnd" to "hWnd"??

shanzy1980

Christian Graus22-Aug-05 12:40

22-Aug-05 12:40

It has a m_hWnd property, from memory. MFC is a wrapper for Win32, so it's all in there.

Christian Graus - Microsoft MVP - C++

shanzy22-Aug-05 12:50

shanzy

22-Aug-05 12:50

Thank you!

But when I code like this:

::ShowWindow(m_hWnd,SW_SHOWNORMAL);

I got a error: error: identifier "m_hWnd" is undefined

I want to know which WIN32API can change a handle to a pointer to Class??

shanzy1980

Christian Graus22-Aug-05 13:03

22-Aug-05 13:03

I meant m_pMainWnd->m_hWnd, and I said I *think*, I expected you'd use intellisense to work out how close I was.

shanzy1980 wrote:
::ShowWindow(m_hWnd,SW_SHOWNORMAL);

Ah.... If you call ShowWindow without the ::, I think there's a method on the class. Or you can do this:

::ShowWindow(*this, SW_SHOWNORMAL);

because when you deference the point, there's an operator HWND.

shanzy1980 wrote:
I want to know which WIN32API can change a handle to a pointer to Class??

None, that can't work. Win32 came first, so the framework knows about Win32, Win32 does not know about MFC. Win32 is for use in C as well, so it cannot support classes at all.

Christian Graus - Microsoft MVP - C++