C / C++ / MFC Discussion Boards

Re: STL problem

Taka Muraoka26-Dec-02 15:52

Taka Muraoka

26-Dec-02 15:52

Well, unless you give us some details of the problem, you might be better off trying here[^]... Smile | :)

he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)

Awasu v0.4a[^]: A free RSS reader with support for Code Project.

Re: STL problem

RobJones26-Dec-02 16:00

RobJones

26-Dec-02 16:00

Taka Muraoka wrote:
you might be better off trying here[^]...

LOL

Yeah please post the error you are getting..

Re: STL problem

Dor26-Dec-02 16:20

Dor

26-Dec-02 16:20

Well, i include all the right things and it gives me this error on the line that i declare the list object on:
c:\program files\microsoft visual studio\vc98\include\ios.h(146) : error C2872: 'streambuf' : ambiguous symbol

I know that the code works when its not using MFC, this error only comes up when in an MFC project
Cheers
Dor

Re: STL problem

Taka Muraoka26-Dec-02 16:26

Taka Muraoka

26-Dec-02 16:26

This is almost certainly caused by your having #include'd mismatching files. Most STL objects come in two versions, one that lives in the global namespace (this is the old style) that you get by #include'ing <iostream.h> The newer version lives in the std namespace - you this by #include'ing <iostream> (nb: no ".h")

So if you #include *both* files and have a using namespace std directive somewhere, when the compiler finds a reference to an STL class, streambuf in your case, it has two matching possibilities i.e. ::streambuf and std::streambuf and doesn't know which one to use.

he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)

Awasu v0.4a[^]: A free RSS reader with support for Code Project.

Re: STL problem

Dor26-Dec-02 16:51

Dor

26-Dec-02 16:51

But the #include <list> only appears once in the project.
should i be using using namespace std; with this version, and should it appear in the header file of the class, and should it be global or local to the class?
sorry, im bombarding you with questions!
Cheers
Dor

Re: STL problem

Taka Muraoka26-Dec-02 16:56

Taka Muraoka

26-Dec-02 16:56

You need to be careful when typing in #include statements here. the < looks like the start of an HTML tag and doesn't get processed properly - use <

Never put "using namespace std" in a header file - it should always go in the .cpp file, *after* all your #include's. It is not something that is global/local to a class but instead something that relates to an entire file, during the compilation process.

This kind of thing is almost impossible to track down without having access to a full copy of the source. The reason why it is working previously but not with MFC is that MFC is #include'ing its own version of the STL headers, probably the old .h ones while your code is #include'ing the new ones. I would try fiddling around with your #include's. You might want to turn off pre-compiled headers while you're doing this since it will almost certainly cause you grief Smile | :)

he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)

Awasu v0.4a[^]: A free RSS reader with support for Code Project.

Re: STL problem

Dor26-Dec-02 17:08

Dor

26-Dec-02 17:08

Cool, Thanks heaps for you help
Dor

About image of drag&drop.

tianyang@vip.163.com26-Dec-02 15:27

tianyang@vip.163.com

26-Dec-02 15:27

Now I using OLE to implement drag&drop. the OLE does not do more thing about image show unless a simple state cursor, I would like listen your think about maintain a image show between drop source AND drop target when user draging.

Thanks

Re: About image of drag&drop.

KaЯl26-Dec-02 23:41

KaЯl

26-Dec-02 23:41

You could manage yourself the drawing of the image when mouse moves if drag&drop occurs in the same application, and after having determinate the image to draw when dragging begins.

One small village of indomitable geeks still holds out against the invaders. And life is not easy for the managers legionaries who garrison the fortified camps of Microsoftum, Javum, Ceplumplum and Vebasum

How to dynamically change media type with YV12 format frames in DirectShow?

Bert_Chen26-Dec-02 15:02

Bert_Chen

26-Dec-02 15:02

Hi.

I want to display YV12 format frames by building a FilterGraph in DirectShow. Those frames are captured from a file. So, I create a source filter inherited from CSource and a output pin inherited from CDynamicOutputPin. Then, I connect this source filter with the Video Renderer filter which is supported by DirectX 8.0 (The CLSID of that filter is CLSID_VideoRenderer).

In DirectX 8.0 SDK, it emphasizes that the Video Renderer, when it is initially connected to the upstream filter, will always insist on a RGB format, so I should let the Video Renderer negotiate a dynamic format change to the appropriate YUV color space after the graph goes into a run state.

But, it only works in the RGB exchange (ex: RGB32 to RGB24). If I attempt to change the output formats into YV12, the return value of the function IPinConnection::DynamicQueryAccept running in CDynamicOutputPin::ChangeMediaType fails. Why??

I think that it could be the argument's problem. Before the output pin of my source filter calls the ChangeMediaType function, we should prepare a CMediaType argument for it. The CMediaType argument is filled with the new media type we want.

The following is my settings of the CMediaType:

　　majortype = MEDIATYPE_Video;
　　subtype = MEDIASUBTYPE_YV12;
　　formattype = FORMAT_VideoInfo;
　　pbFormat = (BYTE *)pVideoInfo;
　　cbFormat = sizeof(VIDEOINFOHEADER);

How to setting up the data of VIDEOINFOHEADER will be fine for YV12 type??

And, the format type (FORMAT_VideoInfo) is correct??

Thanks.

Bert Chen

problem using tab control

Member 11729326-Dec-02 13:08

Member 117293

26-Dec-02 13:08

Hi everyone

I'm developing an application, and in that application i added a dialog on his right, this dialog have a tab control on it. The problem is that i can not see the tabs on the dialog when i add more tabs, only appear the tab control with no tabs.

thanks

Re: problem using tab control

Dor26-Dec-02 15:32

Dor

26-Dec-02 15:32

Hi there,
When ever ive used tab control, ive used something similar to the following code:

CTabCtrl m_MainTabCtrl;<br />
 TC_ITEM TabCtrlItem;<br />
 TabCtrlItem.mask = TCIF_TEXT;<br />
 TabCtrlItem.pszText = "Tab1";<br />
 m_MainTabCtrl.InsertItem( FILE_RESULTS_VIEW, &TabCtrlItem );<br />
 TabCtrlItem.pszText = "Tab2";<br />
 m_MainTabCtrl.InsertItem(FILE_SCAN_VIEW , &TabCtrlItem);

This will show the Tabs only, I then insert a CDialog and show and hide the dialog as needed by the tabs. Hope this helps.

Re: problem using tab control

Member 11729327-Dec-02 5:21

Member 117293

27-Dec-02 5:21

Hi´
Look all the above code i've done it before i post my message, but it just doesn't work. when i try to put a tab in a dialog app it work. An example of my app is the msdn , with a tab in the left.

Re: problem using tab control

Dor27-Dec-02 11:47

Dor

27-Dec-02 11:47

All i know is that i created a dialog box, then put a tab control in that. You have to make sure that you create and show the dialog that holds the tab. I don't know what else to say sorry. The only way i can help you further is to see your code.
Dor

Re: problem using tab control

Mangesh Sardesai26-Dec-02 21:56

Mangesh Sardesai

26-Dec-02 21:56

Use the CTabCtrl::InsertItem to create the tabs...

Smile | :)

regards

M$

WriteFile = slow; fwrite = fast; me = sad;

C^hris L^osinger26-Dec-02 12:57

C^hris L^osinger

26-Dec-02 12:57

fwrite, fread and friends are easily many times faster than WriteFile, ReadFile and friends, when doing lots of small reads and writes. this means my program is many times slower than it used to be.

are there any ways to improve the performance of the Win32 I/O operations when doing lots of little reads/writes? (no, rewriting the code that does these reads/writes is not an option (LibTiff, LibPNG, JpegLib, etc).

fyi, here's my open-for-read:

fileHandle = CreateFile(pFileName, GENERIC_READ, FILE_SHARE_READ, 
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

-c

I'm not the droid you're looking for.

ThumbNailer

Re: WriteFile = slow; fwrite = fast; me = sad;

Neville Franks26-Dec-02 13:13

Neville Franks

26-Dec-02 13:13

I'm a bit surprised you are seeing a big difference. Are you opening and closing the file each time? If so that would have a big hit. What about doing a big dummy read to get the entire file cached.

If you *could* rewrite the code then I'd suggest trying memory mapped files.

Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program

Re: WriteFile = slow; fwrite = fast; me = sad;

C^hris L^osinger26-Dec-02 13:30

C^hris L^osinger

26-Dec-02 13:30

Neville Franks wrote:
I'm a bit surprised you are seeing a big difference

in some cases, the difference is over 12x. CreateFile etc is essentially unusable, but it has the feature that you can pass a HANDLE out of a DLL, while you can't pass a FILE* out.

Neville Franks wrote:
Are you opening and closing the file each time?

no. it just the fact that i'm lots of little reads/writes (parsing images, etc).

-c

I'm not the droid you're looking for.

ThumbNailer

Re: WriteFile = slow; fwrite = fast; me = sad;

Neville Franks26-Dec-02 13:46

Neville Franks

26-Dec-02 13:46

Chris Losinger wrote:
while you can't pass a FILE* out.

why not?

So the DLL code isn't yours and thus can't be changed or it is yours and you don't want to change it because ...

Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program

Re: WriteFile = slow; fwrite = fast; me = sad;

C^hris L^osinger26-Dec-02 13:50

C^hris L^osinger

26-Dec-02 13:50

Neville Franks wrote:
why not?

because the DLL and the EXE will be using different copies of the CRT.

-c

I'm not the droid you're looking for.

ThumbNailer

Re: WriteFile = slow; fwrite = fast; me = sad;

Neville Franks26-Dec-02 13:57

Neville Franks

26-Dec-02 13:57

Chris Losinger wrote:
because the DLL and the EXE will be using different copies of the CRT.

So? I assume the DLL opens the file with fopen, the returned FILE* points to memory in the .EXEs heap, in which case it can happilly use it. Or am I missing something fundamental here.

Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program

Re: WriteFile = slow; fwrite = fast; me = sad;

C^hris L^osinger26-Dec-02 14:16

C^hris L^osinger

26-Dec-02 14:16

Neville Franks wrote:
Or am I missing something fundamental here

each CRT copy has its own table of file handles, these are not shared between modules. so if you fopen a file in a DLL and get a FILE * of "53", that will probably not correspond to anything meaningful in your EXEs file handle table.

the HANDLE that comes from a CreateFile, however, is maintained by the OS, not the CRT, so you can share that between modules without problems.

-c

I'm not the droid you're looking for.

ThumbNailer

Re: WriteFile = slow; fwrite = fast; me = sad;

Neville Franks26-Dec-02 14:39

Neville Franks

26-Dec-02 14:39

I've looked in the VC++ fopen docs and can't see anything about each CRT instance getting it's own table. Looking at the CRT code it uses _malloc_crt() to allocate a stream object.

I don't understand why you would be using the file handle anyway. Surely you just pass the FILE* back to some DLL function to read/write. And if the CRT is in a DLL why is their another "handle table" in the .EXE.

Have you actually proved there is a problem with fopen et.all.?

Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program

Re: WriteFile = slow; fwrite = fast; me = sad;

C^hris L^osinger26-Dec-02 15:13

C^hris L^osinger

26-Dec-02 15:13

Neville Franks wrote:
Have you actually proved there is a problem with fopen et.all.?

yes, a 2 minute DLL project can prove this:

in a DLL:

typedef struct strct_t
{
   FILE *fp;
} strct;

void __stdcall OpenAFile(strct * theStruct)
{
   theStruct->fp = fopen("c:\\autoexec.bat", "r");
}

in the EXE:

strct s;
OpenAFile(&s);
fclose(s.fp);

it crashes in the fclose.

Neville Franks wrote:
Looking at the CRT code it uses _malloc_crt() to allocate a stream object.

and then it associates one of the entries in the __piob array to the stream. this array is global to the CRT instance (look in crt\src\_file.c).

a quick skip through Google will show dozens of instances of this problem. and the answer is always "use CreateFile" or "link to a shared CRT". unfortunately, the second is not an option for me, either.

the problem is really: how to make ReadFile/WriteFile behave in a manner worthy of being the low-level file operation on a modern OS?

-c

I'm not the droid you're looking for.

ThumbNailer

Re: WriteFile = slow; fwrite = fast; me = sad;

Neville Franks26-Dec-02 15:50

Neville Franks

26-Dec-02 15:50

Chris Losinger wrote:
"link to a shared CRT". unfortunately, the second is not an option for me, either.

I missed the shared CRT bit. Guess I lead you down the wrong track. Sorry about that.

Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program

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