C / C++ / MFC Discussion Boards

topcatalpha27-May-13 2:56

27-May-13 2:56

Hi,

I like to gather some coding guideline tools for C. More specific for integration into a CI system showing us some statistics of the code quality.

Can anyone post some suggestions, eventually with feedback or experience about the tool?

regards.

T.

Re: Coding guidelines C

Maximilien27-May-13 7:08

Maximilien

27-May-13 7:08

topcatalpha wrote:
More specific for integration into a CI system

What's a CI system ?

Anyway, coding guidelines are quite subjective, google for a few of them and pick whatever looks nice and applicable to your organization (or yourself).

For example, the IBM[^] one looks good.

Nihil obstat

Re: Coding guidelines C

topcatalpha28-May-13 20:41

topcatalpha

28-May-13 20:41

CI = Continious Integration.

Well we reviewed some tools but it would be nice if we had some feedback from users who are actually using them.

thx,

K

PlaySoundA does not return within injected DLL

Furblog Sidloth26-May-13 0:42

Furblog Sidloth

26-May-13 0:42

Hi, i have the following problem:

I have a process which uses PlaySoundA[^] WINAPI function to play a specific sound (let's be it "c:\test.wav"). So the process has already loaded the needed "winmm.dll"

I want to play the same sound when the DLL is injected into the process, so the code looks like:

C++

#define WINVER 0x600
#define _WIN32_WINDOWS 0x600
#define _WIN32_WINNT 0x600

#include <windows.h>

typedef bool __stdcall (*psfunc)(LPCTSTR pszSound, HMODULE hmod, DWORD fdwSound);

void play() {
    psfunc ps;
    HMODULE winmm = GetModuleHandle("winmm");;
    ps = (psfunc)GetProcAddress(winmm, "PlaySoundA");
    ps("c:\\test.wav", 0, SND_FILENAME | SND_ASYNC);
}

BOOL __stdcall DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved)
{
    switch (dwReason)
    {
        case DLL_PROCESS_ATTACH:
            OutputDebugString("play before");
            play();
            OutputDebugString("play after");
            break;

        case DLL_PROCESS_DETACH:
            break;

        case DLL_THREAD_ATTACH:
            break;

        case DLL_THREAD_DETACH:
            break;
    }
    return TRUE;
}

The dll is injected correctly via CreateRemoteThread & LoadLibrary.
But the sound is never played and the dll is blocking at the call of

C++

ps("c:\\test.wav", 0, SND_FILENAME | SND_ASYNC);

Trying to exit the process freezes too because of the blocking thread.
Why does it never return? Procss Monitor doesn't show any error.
How can I solve this?

Re: PlaySoundA does not return within injected DLL

Richard MacCutchan26-May-13 0:54

Richard MacCutchan

26-May-13 0:54

~~Are you certain that GetProcAddress is returning a valid handle?~~
See the warning at http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx[^]. I do not think you should be calling your play function inside DllMain.

Use the best guess

modified 26-May-13 7:20am.

Re: PlaySoundA does not return within injected DLL

Furblog Sidloth26-May-13 20:39

Furblog Sidloth

26-May-13 20:39

Oh, I didn't see that.
So I called the function via CreateRemoteThread too and it's working. Thank you!
It would be nice to know what things are allowed/disallowed in DllMain.

Re: PlaySoundA does not return within injected DLL

Richard MacCutchan26-May-13 21:38

Richard MacCutchan

26-May-13 21:38

Furblog Sidloth wrote:
It would be nice to know what things are allowed/disallowed in DllMain.

I agree, the documentation could be better. However, my understanding is that you should not do anything more than initialise the odd static variable or class, and save a handle to the DLL itself. Anything that takes you out of DllMain is not allowed and can lead to problems - as you already discovered.

Use the best guess

Re: PlaySoundA does not return within injected DLL

Erudite_Eric27-May-13 5:48

Erudite_Eric

27-May-13 5:48

Not only that he has no error checking....

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

Nothing to say.

Re: PlaySoundA does not return within injected DLL

Richard MacCutchan27-May-13 5:53

Richard MacCutchan

27-May-13 5:53

Seems to be fairly standard these days.

Use the best guess

Re: PlaySoundA does not return within injected DLL

Erudite_Eric27-May-13 10:54

Erudite_Eric

27-May-13 10:54

Exception handling will clean up the crap.....

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

Nothing to say.

Re: PlaySoundA does not return within injected DLL

Richard MacCutchan27-May-13 20:59

Richard MacCutchan

27-May-13 20:59

I sometimes wonder if some of the course being taught these days even mention error checking.

Use the best guess

Modeless Dialog CricheditCtrl Issues

ForNow25-May-13 19:34

ForNow

25-May-13 19:34

Hi,

I am having a number of problems Getting my richedit to work with my Modless Dialog Box

it started with scrolling as I was unable to get the Current Line and then I while trying to debug it

I noticed the I was I using DDX to connect my crichedit class with the resource defined window

which the documentation says only works for modal however when I comment out the UpdateData

and used the CRichEdtCtrl::Create to connect my windows class to the resource window none the Streamed in data is displayed I'll display the code along with the resource statements

The Create of the modeless Dialog

C++

ret =  progdbg->Create(IDD_PROGDBG,(CWnd *)this);

C++

BOOL CprogDebug::OnInitDialog()
{
  int FirstVisible; 
  long start, end, theline;
  myedit = new CProgedit;       // allocate the richedit
		CRect myrect(17,39,735,273);
		myedit->SetOptions(ECOOP_OR, ECO_AUTOVSCROLL |  ECO_AUTOHSCROLL);
  //  myedit->Create(WS_CHILD| ES_AUTOHSCROLL | ES_AUTOVSCROLL | ES_MULTILINE,myrect,this,IDC_RICHEDIT22);
	 UpdateData(FALSE);  // connect to dilog object
         EDITSTREAM es;
           

   // Set the ENM_REQUESTRESIZE event flag
 //  myedit->SetEventMask( ENM_REQUESTRESIZE ); // set notificate to keep number of charcters in view

   // Force the control to issue a EN_REQUESTRESIZE notification
 //  myedit->RequestResize( );


   CStdioFile *fileptr = new CStdioFile;
   fileptr->Open(proglisting,CFile::typeBinary);
           es.dwCookie = (DWORD) fileptr;
        es.dwError = 0;
        es.pfnCallback = (EDITSTREAMCALLBACK) readlisting;
         myedit->StreamIn(SF_TEXT, es);
		  myedit->SetFocus();
	//	 myedit->GetSel(start,end);
		  theline = myedit->LineFromChar(myedit->LineIndex(-1));
	//	 FirstVisible = myedit->GetLineCount();
		 
//		FirstVisible = myedit->LineIndex(-1);
		 myedit->LineScroll(-theline,0);
		 myedit->HideSelection(TRUE,FALSE);
			        // Call MFC Oninit
          ShowWindow(SW_SHOW);
      //  progeditptr = new CProgedit();
		CDialog::OnInitDialog(); 	
        return TRUE;
}

C++

void CprogDebug::DoDataExchange(CDataExchange* pDX)
 {

//
//        //should precede the DDX and DDV routines
   CDialog::DoDataExchange(pDX);
        // Attach
        DDX_Control(pDX,IDC_RICHEDIT22,(CWnd &)*myedit); // connect rich edit
 //       DDX_Control(pDX,IDC_DESCRIP,descrip);

 //  DDX_Text(pDX, (int) IDC_DESCRIP, mytcpipmess);

 }

Re: Modeless Dialog CricheditCtrl Issues

Richard MacCutchan26-May-13 0:45

Richard MacCutchan

26-May-13 0:45

This is not the correct way to use a dialog; switch it to a modal type.

Use the best guess

Re: Modeless Dialog CricheditCtrl Issues

ForNow26-May-13 2:29

ForNow

26-May-13 2:29

meaning I can't use I cant use RichEdit with modeless

Re: Modeless Dialog CricheditCtrl Issues

Richard MacCutchan26-May-13 2:32

Richard MacCutchan

26-May-13 2:32

Why would you want to? It offers no advantages and just makes your code far more complex than it needs to be. Use dialogs the way they are meant to be used and your life will be so much easier.

Use the best guess

Re: Modeless Dialog CricheditCtrl Issues

ForNow26-May-13 2:45

ForNow

26-May-13 2:45

I want to have richedit with a window that I can move around mot modal with just a ok or cancel button

If modeless and richedit is out of the picture then maybe I should I should just use a regular child

window

Re: Modeless Dialog CricheditCtrl Issues

Richard MacCutchan26-May-13 3:02

Richard MacCutchan

26-May-13 3:02

ForNow wrote:
I want to have richedit with a window that I can move around

And why do you think a modal dialog cannot do that?

Use the best guess

Re: Modeless Dialog CricheditCtrl Issues

ForNow26-May-13 3:09

ForNow

26-May-13 3:09

Model as in Do.Modal are very inflexible
Used to gather data yes/no. I want to
Display a Mainframe assembler program listing
In a richedit manipulate the current selection
Have other controls/windows display
Register information can do all that with a
Modal

Re: Modeless Dialog CricheditCtrl Issues

Richard MacCutchan26-May-13 3:31

Richard MacCutchan

26-May-13 3:31

ForNow wrote:
Model as in Do.Modal are very inflexible

Quite the opposite; you can do (more or less) anything you like in a modal dialog. However, given the description of what you want to do, it may not be the best choice. The issues is to decide what features you wish to use and then work out which type of window you need. Perhaps a normal frame window would do what you want, but running in a separate thread. Or, go back to a modeless dialog, but accepting that you cannot use those features that are restricted to modals.

Use the best guess

Re: Modeless Dialog CricheditCtrl Issues

ForNow26-May-13 3:48

ForNow

26-May-13 3:48

So then I can use richedit with modeless when i do CRichedt::create the stream in callback gets control
But the data is not displayed in the CRichedit

Re: Modeless Dialog CricheditCtrl Issues

Richard MacCutchan26-May-13 3:53

Richard MacCutchan

26-May-13 3:53

ForNow wrote:
But the data is not displayed in the CRichedit

Then you need to investigate why, and add whatever code is necessary. Check out the documentation for the CRichedit class.

Use the best guess

Re: Modeless Dialog CricheditCtrl Issues

ForNow26-May-13 5:48

ForNow

26-May-13 5:48

thanks again for your help forgot the WS_VISIBLE flag on the CRichEditCtrl::Create

another issue the TCP/IP registry setting per the MS Knoweledbase article got my sockets to connect the MainFrame

Thanks Again

Re: Modeless Dialog CricheditCtrl Issues

David Crow29-May-13 4:52

David Crow

29-May-13 4:52

ForNow wrote:
myedit = new CProgedit; // allocate the richedit
CRect myrect(17,39,735,273);
myedit->SetOptions(ECOOP_OR, ECO_AUTOVSCROLL | ECO_AUTOHSCROLL);

Why make the rich edit control on the heap? Put it on the stack like any other control variable. Way simpler.

ForNow wrote:
CDialog::OnInitDialog();

Any particular reason why this statement is (second to) last instead of first?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

modified 29-May-13 15:21pm.

Re: Modeless Dialog CricheditCtrl Issues

ForNow29-May-13 8:30

ForNow

29-May-13 8:30

Why make the dialog on the heap. I'm doing inter process communication with a console program
And I am afraid that if create the dialog on the
Stack some of the information will get lost
As I want the dialog active durning the time I am
Communicating with the console program

When I put CDialog::Initinstnce as the first statement
In my overridable control never came back from it

Re: Modeless Dialog CricheditCtrl Issues

David Crow29-May-13 9:20

David Crow

29-May-13 9:20

ForNow wrote:

When I put CDialog::Initinstnce as the first statement

You mean OnInitDialog()?

ForNow wrote:

In my overridable control never came back from it

Did you remember to call AfxInitRichEdit() in the app's InitInstance() method()?

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