C / C++ / MFC

Rajkumar R8-Feb-08 1:49

8-Feb-08 1:49

~Jabeen~ wrote:
when i pass CLSID_AudioRendererCategory it gives me 6 audio renderer values

this is because there r 2 filter instances (DirectSound And Waveout) for each audio device (
Device 1 (WaveOut, DirectSound) +
Device 2 (WaveOut, DirectSound) +
default (selected Device (Device 1/2)) (waveout, DirectSound)
= 6
)

to select a particular renderer u may need to compare the friendly names of the enumerated monikers through BindToStorage() and create the filter instance using IMoniker::BindToObject(),
the friendly names are of the format

"The DirectSound instance has the friendly name "DirectSound: DeviceName," where DeviceName is the name of the device. The WaveOut instance has the friendly name DeviceName."

~Jabeen~ wrote:
how can i configure it to 2 sound devices rather than renderers

above details gives the idea for doing in directshow.

rjkg8-Feb-08 1:58

rjkg

8-Feb-08 1:58

when you render the desired file to the sound card you must add the
sound card filter to the graph then RenderFile() method automatically
connect to that particular sound card , other wise it will connect to the
default sound card

Rajesh

Rajkumar R8-Feb-08 4:20

8-Feb-08 4:20

rajeshgupta1253 wrote:
you must add the
sound card filter

how to do this is the question

Rajkumar R8-Feb-08 2:23

Convert CString to DWORD or CString to COLORREF

8-Feb-08 2:23

repost as previous not displayed correctly

~Jabeen~ wrote:
when i pass CLSID_AudioRendererCategory it gives me 6 audio renderer values

"The DirectSound instance has the friendly name "DirectSound: DeviceName," 
where DeviceName is the name of the device. 
The WaveOut instance has the friendly name DeviceName."

~Jabeen~ wrote:
how can i configure it to 2 sound devices rather than renderers

above details gives the idea for doing in directshow.
or check for DRVM_MAPPER_PREFERRED_SET in waveOutMessage

orihime8-Feb-08 0:06

orihime

8-Feb-08 0:06

How do I convert CString to DWORD or CString to COLORREF?

For example: CString color = "0xFF00FF"

Thanks!

Re: Convert CString to DWORD or CString to COLORREF

Rajkumar R8-Feb-08 0:11

Re: Convert CString to DWORD or CString to COLORREF [modified]

8-Feb-08 0:11

strtoul ?

CPallini8-Feb-08 0:20

Re: Convert CString to DWORD or CString to COLORREF

8-Feb-08 0:20

use strtol [^], for instance

char * p;
TCHAR * p;
CString sz=_T("0xFF00FF");
DWORD dw = _tcstol(sz,&p, 16);
COLORREF cr =_tcstol(sz,&p, 16);

Be aware that COLORREF value maybe set in way you don't expect, for instance

COLORREF cr1 =_tcstol(_T("0x1F00FF"),&p, 16); // cr1 = 0x001f00ff
COLORREF cr2 = RGB(0x1F, 0x00, 0xFF); // cr2 = 0x00ff001f

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

modified on Monday, February 11, 2008 3:46 AM

orihime10-Feb-08 18:09

orihime

10-Feb-08 18:09

Instead of using char * p;

I used wchar_t *p;

Thank you so much for the help! Smile | :)

Re: Convert CString to DWORD or CString to COLORREF

CPallini10-Feb-08 21:46

privileged instruction exception in ultimate grid

10-Feb-08 21:46

You're right, the proper one is

TCHAR * p;

Anna Anna7-Feb-08 22:44

Anna Anna

7-Feb-08 22:44

Hi all,

I'm using the UltimateGrid attached to a view. The view has from previous work already the LButton-Down-Event handled. The handling involves the Document of my MFC application. The integrated Grid doesn't know about the document. Therefore the OnLClicked-Function is supposed to call the appropriate function of the view. I'm doing it using the following code:

---
CWnd* pParent = GetParent();
ASSERT(pParent);

NMHDR nmhdr;
nmhdr.code=NM_CLICK;
nmhdr.hwndFrom=m_hWnd;
nmhdr.idFrom=GetDlgCtrlID();

pParent->SendMessage(WM_NOTIFY, 0, (LPARAM)&nmhdr);
---

Catching the Event in the view's message map using ON_NOTIFY(NM_CLICK, 1234, OnLButtonDown)

Works in DEBUG Mode, crashes in Release Mode with an "privileged instruction"-exception.

Does anyone has an idea?

I very appreciate any help, Anna

Re: privileged instruction exception in ultimate grid

Iain Clarke, Warrior Programmer8-Feb-08 1:12

Iain Clarke, Warrior Programmer

8-Feb-08 1:12

Make sure you the signature of your handling function correct. Do a search for ON_NOTIFY, and you get:
afx_msg void memberFxn( NMHDR * pNotifyStruct, LRESULT * result );

Similarly, OnLButtonDown is a TERRIBLE name. It matches up with the handler for ON_WM_LBUTTONDOWN.

Because the ON_XXXX macro casts the 3rd parameter, it won't tell you you're using the wrong function signature, and you'll just crash. As debug mode has lots of NOPs about, the chances of crashing are much lower.

Iain.

Iain Clarke appearing in spite of being begged not to by ^CPallini.

Re: privileged instruction exception - Problem solved

Anna Anna8-Feb-08 3:27

Anna Anna

8-Feb-08 3:27

Hi Iain,

thanks a lot. I've seen this, but didn't quite understand. I thought I could go an easy way and use the original OnLButtonDown function. I can see now that is horrible nonsense. I created my own
afx_msg void OnLButtonDownFromGrid( NMHDR * pNotifyStruct, LRESULT * result ), implemented all the stuff from the old OnLButtonDown and IT WORKS!

Thanks again,
Anna

A very strange problem (to me at least) .....

Still learning how to code7-Feb-08 22:28

7-Feb-08 22:28

I created a very simple class (CLogFile) to enable me to trace events within my applications (It writes diagnostic messages to a hard disk file during exceution of the app) Admittedly, I have generally used this in the past with Dialog-based apps, but now I have included it in a Doc/View MDI app and have a peculiar problem.
I should explain that my CLogFile class is instantiated in the InitInstance function of the app, and a global pointer created pointing to the CLogFile object. In functions that I want to trace, I simply dereference the global pointer and thereby call the Add(CString szMsg) public member function to add the string to the file.
This all works fine in all locations in which I have used it to date, but, currently having a problem in OnDraw(), I tried using it there and got a 0xC0000005 access exception but (and this is the interesting bit) on the SECOND time through !! I get the same problem in OnPrepareDC(). I have now generated an vanilla (i.e. as initially produced by AppWizard) doc/view app and added the LogFile class, and get the same problem. It appears that the exception is being generated because the member variables in the CLogFile object have been corrupted. In an attempt to find the source of the corruption, I opened a memory window and displayed the area where the class members are located. The data is correct after exiting AfxWndProc() and then it enters (windows) assembler code. Still tracing, I get to a call where it won't step through to the target. Locating the target address, I find that the location is "mid-instruction". I have no doubt that this is then leading to the access exception. Can anybody give me a clue on how this corruption might be occuring ? I just can't understand why it works perfectly well in (supposedly) ALL other areas of the code, and yet fails in this way in these two functions. Any help/explanation would be greatly appreciated !

Doug

CPallini7-Feb-08 23:06

7-Feb-08 23:06

I think you need to post some code.
Smile | :)

Still learning how to code7-Feb-08 23:13

7-Feb-08 23:13

Here's the CLogFile class (.h and .cpp)

#if !defined(AFX_LOGFILE_H__55017EEE_12D9_4F35_9CBC_4C111B28982A__INCLUDED_)
#define AFX_LOGFILE_H__55017EEE_12D9_4F35_9CBC_4C111B28982A__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
// LogFile.h : header file
//

/////////////////////////////////////////////////////////////////////////////
// LogFile

class CLogFile : public CStatic
{
// Construction
public:
CLogFile();

// Attributes
public:

// Operations
public:

// Overrides
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(LogFile)
//}}AFX_VIRTUAL

// Implementation
public:
void Add(CString szMessage);
CFile fLogFile;
CString m_szRootPath;
void Start(BOOL bAppend);
CString m_szLogFile;
CString m_szLogFilePath;
CLogFile(CString szLogFile, BOOL bAppend = FALSE);
virtual ~CLogFile();

// Generated message map functions
protected:
//{{AFX_MSG(CLogFile)
// NOTE - the ClassWizard will add and remove member functions here.
//}}AFX_MSG

DECLARE_MESSAGE_MAP()
};

/////////////////////////////////////////////////////////////////////////////

//{{AFX_INSERT_LOCATION}}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.

#endif // !defined(AFX_LOGFILE_H__55017EEE_12D9_4F35_9CBC_4C111B28982A__INCLUDED_)

// LogFile.cpp : implementation file
//

#include "stdafx.h"
#include "LogFile.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

/////////////////////////////////////////////////////////////////////////////
// CLogFile

CLogFile::CLogFile()
{
}

CLogFile::~CLogFile()
{
}

BEGIN_MESSAGE_MAP(CLogFile, CStatic)
//{{AFX_MSG_MAP(LogFile)
// NOTE - the ClassWizard will add and remove mapping macros here.
//}}AFX_MSG_MAP
END_MESSAGE_MAP()

/////////////////////////////////////////////////////////////////////////////
// CLogFile message handlers

CLogFile::CLogFile(CString szLogFile, BOOL bAppend)
{
m_szRootPath = "C:\\";
m_szLogFile = szLogFile;
m_szLogFilePath.Format("%s\\%s.log",m_szRootPath,szLogFile);
Start(bAppend);
}

void CLogFile::Start(BOOL bAppend)
{
CString szCopyFilePath, szFrom, szTo;
szCopyFilePath.Format("%s\\%s.bak",m_szRootPath,m_szLogFile);

// Push down LIFO stack of LogFiles
for( int iIndex = 5; iIndex > 0; iIndex--)
{
szFrom.Format("%s%sLog%i.bak",m_szRootPath,m_szLogFile,iIndex-1);
szTo.Format("%s%sLog%i.bak",m_szRootPath,m_szLogFile,iIndex);
CopyFile(szFrom,szTo,FALSE);
}
// Copy .log to .bak0
szTo.Format("%s%sLog%i.bak",m_szRootPath,m_szLogFile,iIndex);
CopyFile(m_szLogFilePath,szTo,FALSE);

BOOL bRC;
if(bAppend)
bRC = fLogFile.Open( m_szLogFilePath, CFile::modeWrite );
else
bRC =fLogFile.Open( m_szLogFilePath, CFile::modeCreate | CFile::modeWrite );

CString szMsg;
if(bRC == 0)
{
szMsg.Format("File not found %s",m_szLogFilePath);
AfxMessageBox(szMsg);
}
CTime TimeNow = CTime::GetCurrentTime();
CString szDate = TimeNow.Format( "%A, %B %d, %Y" );
//ASSERT( s == "Friday, March 19, 1999" );

CString sMessage, sText;

if(!bAppend)
{
sMessage = "Start of log file ";
sText.Format("%s - %s%c%c",sMessage,szDate,'\r','\n');

fLogFile.Write(sText.GetBuffer(512),sText.GetLength());

sMessage = "-----------------------------------------------------";
sText.Format("%s%c%c",sMessage,'\r','\n');
fLogFile.Write(sText.GetBuffer(512),sText.GetLength());
}
fLogFile.Close();

}

void CLogFile::Add(CString szMessage)
{
fLogFile.Open( m_szLogFilePath, CFile::modeWrite );
fLogFile.Seek( 0,CFile::end);
CString szText;
// Get current time
CTime TimeNow = CTime::GetCurrentTime();
CString szTime;
szTime.Format("%02i:%02i:%02i",TimeNow.GetHour(),TimeNow.GetMinute(),TimeNow.GetSecond());
szText.Format("%s %s%c%c",szTime,szMessage,'\r','\n');
fLogFile.Write(szText.GetBuffer(512),szText.GetLength());

fLogFile.Close();
}

Doug

CPallini7-Feb-08 23:16

7-Feb-08 23:16

Why did it inherit from CStatic?

Still learning how to code7-Feb-08 23:58

7-Feb-08 23:58

CPallini wrote:
Why did it inherit from CStatic?

No reason - my ignorance in selection of base class when I wrote it (didn't know a lot then - still don't !!) Shouldn't be a problem tho', should it ??

Doug

CPallini8-Feb-08 0:05

8-Feb-08 0:05

Probably you don't need to inherit it at all.
I don't know if it is the problem, but I suggest you to drop that inherithance.
You have also to remove all the MESSAGE_MAP stuff.
Smile | :)

Matthew Faithfull8-Feb-08 0:09

Matthew Faithfull

8-Feb-08 0:09

DougButtimer wrote:
Shouldn't be a problem tho', should it ??

It shouldn't but it probably is, CStatic is an MFC class and encapsulates a Window/Ctrl as well. Firstly you don't need all that overhead and secondly that places all sorts of restrictions on what you can and can't do with the class and introduces assumptions on the part of exisitng MFC code about how your class will behave, even that its first data member will be a hWnd. I still don't understand exactly why you're seeing what you're seeing but I would definitely start with a properly 'vanilla' log file calss that doesn't inherit from an already complex MFC class.

Nothing is exactly what it seems but everything with seems can be unpicked.

Still learning how to code8-Feb-08 0:59

8-Feb-08 0:59

Yes, it would be good to eliminate that possibility - I'll regenerate the class without inheritance and see what happens ! Thanks for the suggestion !

Doug

Still learning how to code8-Feb-08 1:31

8-Feb-08 1:31

As suggested, I made the following three changes to CLogFile:-

1------------------------------------------------------------
class CLogFile //: public CStatic 20080208
{
// Construction

2--------------------------------------------------------------
// DECLARE_MESSAGE_MAP() 20080208

3-------------------------------------------------------------
/* 20080208
BEGIN_MESSAGE_MAP(CLogFile, CStatic)
//{{AFX_MSG_MAP(LogFile)
// NOTE - the ClassWizard will add and remove mapping macros here.
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
*/

I am sorry to say the problem remains as before !!! Sigh | :sigh:

Doug

CPallini8-Feb-08 2:17

8-Feb-08 2:17

Could you also post the code wherein exception happens?

Still learning how to code8-Feb-08 2:37

8-Feb-08 2:37

I can't really post the code where the exception happens ! Execution proceeds through CLogFile, exits OnDraw() and enters basic Windows code As I said in my original posting, I traced through the code and eventually into (windows) assembler and hit that call where the debugger would not step to. A copy of this line in the debugger is:-

7E41B517 call 7E4194A4

and the target of the call is the last byte of the first instruction below (assuming the disassembly is correct) :-

7E4194A1 or eax,dword ptr [esi+edi*2-75h]
7E4194A5 inc esp
7E4194A6 and al,4
7E4194A8 int 2Bh

Up to this pooint the memory window shows that the CLogFile member variable locations hold correct values. Execution past this point results in corrupted values. I'm baffled !!

Doug

CPallini8-Feb-08 2:50