Re: system call too small - C / C++ / MFC Discussion Boards

2buck5615-Jan-10 13:51

15-Jan-10 13:51

Garth, I tried setting the buffer size to 2048 and 4096 but that didn't make a difference. This code is from Jan Axelson's USB code and it works in VC6++ without allocating a buffer size. I did find out that if I turn Unicode off and set it to MBCS the warning messages all disappear.

LunaticFringe, for those two lines of code I was just testing to see if the call to SetLastError would then make an immediate GetLastError call return success. But that didn't work.

Almost all of the GetLastError calls will be removed once I have the application running properly. I just put them in there for test purposes as I am developing the application.

Re: system call too small [modified]

LunaticFringe15-Jan-10 14:31

LunaticFringe

15-Jan-10 14:31

Don't worry about the buffer size - the GetLastError code snippet was lifted from the same MSDN page Garth referenced, down near the bottom of the page. The 0 for minimum buffer size is fine.

L u n a t i c F r i n g e

modified on Friday, January 15, 2010 8:48 PM

Re: system call too small

2buck5615-Jan-10 15:02

2buck56

15-Jan-10 15:02

LunaticFridge,

Thanks for your help. I understand what you are saying about GetLastError. And reading Microsoft's documentation about it makes it seem even less useful. It may be helpful like you say if you already know the API call is failing.

The few places where I want to be aware of failure I put something like this in:

if (DeviceDetected == FALSE)
	DisplayData("Device not detected");
else
	DisplayData("Device detected");

That way I know for sure what the results of a call are.

Again, thanks to you and the others for your help.

Re: system call too small

CPallini15-Jan-10 22:02

CPallini

15-Jan-10 22:02

LunaticFringe wrote:
That's not the point.

Very well said.

LunaticFringe wrote:
GetLastError returns valid information from the last API call that failed; you're interrogating it when the last call succeeded. Not surprisingly, it returns gibbersih.

That's not completely true.In spite of the function name (GetLastError), when a API call succeedes, it often sets last error to 0. Hence, when a API call succeedes and GetLastError is different from zero, the odds are that it refers to an error occurred in a previous API call. That, however, doesn't change the prescription: "use GetLastError just when a API call fails".

Smile | :)

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

[My articles]

Re: system call too small

CPallini15-Jan-10 22:11

CPallini

15-Jan-10 22:11

As L u n a t i c F r i n g e already noted, that's not the point: since CreateFile does NOT fail, hence GetLastError is reporting an error coming from a previous API call (which one?!).
Your approach to error handling is wrong: you've to:

First and always check API return value.
Then (if the API call failed) call GetLastError to retrieve additional information.

Re: system call too small

Garth J Lancaster15-Jan-10 22:41

Garth J Lancaster

15-Jan-10 22:41

CPallini wrote:
First and always check API return value.

Then (if the API call failed) call GetLastError to retrieve additional information.

which is what I said - I think - maybe convoluted (just been drinking French Red wine I bought back from my last trip)

come sta Carlo ?

'g'

Re: system call too small

CPallini15-Jan-10 22:43

CPallini

15-Jan-10 22:43

Garth J Lancaster wrote:
come sta Carlo ?

Bene, grazie!
E tu?
Smile | :)

Re: system call too small

Garth J Lancaster15-Jan-10 22:59

Garth J Lancaster

15-Jan-10 22:59

CPallini wrote:
E tu?

Non c'è male, grazie

Smile | :)

Re: system call too small

CPallini15-Jan-10 23:10

CPallini

15-Jan-10 23:10

Re: system call too small

Bram van Kampen17-Jan-10 6:18

Bram van Kampen

17-Jan-10 6:18

Yes, but you should call GetLastError IMMEDIATELY after it (and immediately before it to clear Previous Errors) Pass the return value of GetLastError to your Error Display function if things go sour!
The way you did it, you have NO guarantee that other API functions are NOT called, before your Display function calls GetLastError().

Regards, Smile | :)

Bram van Kampen

Re: system call too small

Richard MacCutchan15-Jan-10 23:55

Richard MacCutchan

15-Jan-10 23:55

You do not show the code for the DisplayLastError() function. I also wonder why you are casting a character constant to a CString. Chances are that one of these two is causing the erroneous message.

MVP 2010 - are they mad?

Re: system call too small

David Crow16-Jan-10 5:06

David Crow

16-Jan-10 5:06

2buck56 wrote:
Does anyone know what I must do to eliminate the message from GetLastError?

First, CreateFile() is not a boolean function so checking its return value as such is wrong. Second, you need to call GetLastError() as soon as the error is detected, like:

DeviceHandle = CreateFile(detailData->DevicePath,
                          0,
                          FILE_SHARE_READ | FILE_SHARE_WRITE,
                          NULL,
                          OPEN_EXISTING,
                          0,
                          NULL);
  
if (DeviceHandle == INVALID_HANDLE_VALUE)
{
    LPVOID lpMsgBuf;
  
    FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
                  NULL,
                  GetLastError(),
                  MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                  (LPTSTR) &lpMsgBuf,
                  0,
                  NULL);
    ...
    LocalFree(lpMsgBuf);
}

"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

Re: system call too small

CPallini16-Jan-10 7:57

CPallini

16-Jan-10 7:57

DavidCrow wrote:
First, CreateFile() is not a boolean function

Good point, indeed. Smile | :)

Re: system call too small

2buck5616-Jan-10 11:01

2buck56

16-Jan-10 11:01

Richard this is the code for DisplayLastError:

void CHIDTest2008Dlg::DisplayLastError(CString Operation)
{
//Display a message and the last error in the log List Box.
	LPVOID lpMsgBuf;
	USHORT Index = 0;
	CString	strLastError;
	FormatMessage( 
		FORMAT_MESSAGE_ALLOCATE_BUFFER | 
		FORMAT_MESSAGE_FROM_SYSTEM | 
		FORMAT_MESSAGE_IGNORE_INSERTS,
		NULL,
		GetLastError(),
		MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
		(LPTSTR) &lpMsgBuf,
		4096,
		NULL 
	);

	//Display the last error.
	strLastError = Operation + (LPCTSTR)lpMsgBuf; 

	//Trim CR/LF from the error message.
	strLastError.TrimRight(); 
	Index = m_ResultsList.InsertString(-1, strLastError);
	ScrollToBottomOfListBox(Index);
	LocalFree(lpMsgBuf);

And I believe you are correct in saying that the CString cast is causing the error. If I call GetLastError immediately after entering my OnBnClick funtion I get the error. At that point no API call has been made (other than the ones the system is doing). Also, by turning off unicode and going to MBCS, all the error messages disappeared. That points to the CString cast.

Ian, the code you show is the way I am doing it now. Since none of my API calls are failing I am not getting any error messages.

Default path to Desktop with vista

dbell0715-Jan-10 9:52

dbell07

15-Jan-10 9:52

Hi everyone. I'm a newbee that's exhausted the Internet already, so I joined the forum.

I'm attempting to create a file on the Desktop under the Vista environment, which is not user dependent. e.g

ofstream file;
file.open("c:\\%userprofile%\\Desktop\\report.txt");
if (!file){
cerr <<"Unable to open file report.txt";
exit(1);
}

but cannot seem to make this happen on the c drive (desktop).
Thanks in advance.

Re: Default path to Desktop with vista

CoderGirl4215-Jan-10 10:18

CoderGirl42

15-Jan-10 10:18

You should be able to just call %userprofile%\desktop without having the c:\ at the front. if you open your command prompt and type in %userprofile% it'll then give you an error message but it will expand the %userprofile% to it's actual value.

Hope that helps

Re: Default path to Desktop with vista

David Crow15-Jan-10 10:25

David Crow

15-Jan-10 10:25

CoderGirl42 wrote:
...but it will expand the %userprofile% to it's actual value.

Unless it contains spaces.

Re: Default path to Desktop with vista

dbell0715-Jan-10 10:46

dbell07

15-Jan-10 10:46

I see the expansion in which you are speaking of from the cmd window. However, since %userprofile% yields the msg. "...' is not recognized as an internal or external command, operable program or batch file.", I'm wondering if this is the same reason %userprofile% does not work from within my program. I'm beginning to think it's the vista platform Cry | :((

Re: Default path to Desktop with vista

dbell0715-Jan-10 10:49

dbell07

15-Jan-10 10:49

Yes, I've tried various forms... e.g. without c:\ without success...

Re: Default path to Desktop with vista

Rozis16-Jan-10 10:28

Rozis

16-Jan-10 10:28

Maybe stupid but if you open a DOS-window and type in SET (enter) is your userprofile there?

Rozis

Re: Default path to Desktop with vista

Spawn@Melmac18-Jan-10 0:35

Spawn@Melmac

18-Jan-10 0:35

Sorry to say this but I believe you are misunderstanding the use of environment variables.

Apart from the fact that the string you are using is wrong ( the variable already contains the drive letter and as already pointed out may contain spaces) do you know the call you are making with apply environment variable expansion?

I prefer not to leave things to chance by either calling,

ExpandEnvironmentStringsForUser - "http://msdn.microsoft.com/en-us/library/bb762275(VS.85).aspx"

or

SHGetFolderPath - "http://msdn.microsoft.com/en-us/library/bb762181(VS.85).aspx"

Alan

Showing and Closing Dialogs in C++

NightBeforeChirstmas15-Jan-10 9:29

NightBeforeChirstmas

15-Jan-10 9:29

I am trying to build a application consists of four dialogs(Dialog A, dialog B, Dialog C and Dialog D).

In dialog A is you press next button it will go to dialog B, at dialog B if you press cancel button it will go back to dialog A. If next button of dialog B is clicked then it will proceed to dialog C and so on.
For the last dialog, Dialog D, if the Finish button is clicked, it will go back to dialog A.

How can I link all the dialogs to work in the sequence specified.
Should I add dialog B,C,D as custom dialog to dialog A?

In dialog A I wrote the code shown below.where is member variable of CtryDlg which declared as CBDlg type.

/*tryDlg.cpp*/
#include "BDlg.h"

void CtryDlg::OnNext()
{
int nRet = m_dBDlg.modal();

}

In dialog B,

void CBDlg::OnCancelB()
{
int nRet = 5;
EndDialog(nRet);
return;
}

But I keep getting Debug Assertion Failed error when the next button of Dialog A is clicked.
Can someone give me so suggestions?

Thanks.

Re: Showing and Closing Dialogs in C++

Maximilien15-Jan-10 9:31

Maximilien

15-Jan-10 9:31

Can't you use a CPropertySheet in Wizard mode to do this ?

see : http://msdn.microsoft.com/en-us/library/d3fkt014%28VS.80%29.aspx[^]

M.

This signature was proudly tested on animals.

Re: Showing and Closing Dialogs in C++

David Crow15-Jan-10 9:48

David Crow

15-Jan-10 9:48

If you can use Maximilien's suggestion, override CPropertyPage::OnWizardFinish() and return FALSE to keep the sheet open. Then call the sheet's SetActivePage() method.

Re: Showing and Closing Dialogs in C++

Bram van Kampen17-Jan-10 6:35

Bram van Kampen

17-Jan-10 6:35

Run it in an External Function:

{
label1:
    DlgA dlga;
    if(dlga.DoModal()==IDCANCEL)return;

label2:
    DlgB dlgb;
    if(dlgb.DoModal()==IDCANCEL)goto label1;

label3:
    DlgC dlgc;
    if(dlgc.DoModal()==IDCANCEL)goto label2;

etc..
}

Regards,

Bram van Kampen

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