C / C++ / MFC

Re: Recursive directory search

29-Jul-16 22:23

Anthony Appleyard wrote:
Can one application be trusted to run these 6 FindFirstFile, FindNextFile , WIN32_FIND_DATA info; directory-scans at once?

Well it isn't doing them all at once, it is doing them one at a time. If you are concerned about testing your application it is easy enough to create a structure to run your application on. But be aware of the limitations imposed by the MAX_PATH constant as described at FindFirstFile function (Windows)[^].

David Crow1-Aug-16 5:01

David Crow

1-Aug-16 5:01

When the function is called again, all of the context information is pushed onto the stack and the new function call starts. When the function unwinds, the most recent context information is popped from the stack and the function picks up where it left off. This is all handled automatically by the system.

"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

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

variadic templates problem

FriendOfAsherah28-Jul-16 23:49

FriendOfAsherah

28-Jul-16 23:49

Im using this for the first time for mapping a function "f" with variable count of parameters

declarition:

C++

template <class...A> void AllItemsO(void (*f)(A...), A... args)
 {
    // for (auto _F : *this)
    //    if ((_F)) ((_F)->*f)(args);
 }

call in cpp:

C++

AllItemsO<IapVisibilityInfo*, IPickCookie*, MakeSubObjSpecial, AVHC(Object)&>(&IcompDWO3D::SetObjMat, visInfo, pci, doit, obj);

function to call is:
IcompDWO3D::SetObjMat
parameters:
visInfo, pci, doit, obj

compiler always shows up an error C2784

Fehler 1 error C2784: "void CapDWOICollection::AllItemsO(void (__cdecl *)(A...),A...)": template-Argument für "void (__cdecl *)(IapVisibilityInfo *,IPickCookie *,aprivis::MakeSubObjSpecial,aprivis::avhObjectWrapper &,A...)" konnte nicht von "void (__thiscall component::IcompDWO3D::* )(IapVisibilityInfo *,IPickCookie *,aprivis::MakeSubObjSpecial,aprivis::avhObjectWrapper &)" hergeleitet werden.

looking at what I have shown bold, it seems that it cannot spread the functionparameters form the A... variadic to single paarameters?
A non variadic verison with 2 Parameters looks like this and works:

C++

template <class T1, class T2> void AllItemsO2(void (*f)(T1, T2), T1 p1, T2 p2) 
{ for (auto _F : *this) if (_F) ((_F)->*f)(p1, p2); }

any help for my syntax?

Trying to understand my mistake... with pointers

Blubbo28-Jul-16 8:04

Blubbo

28-Jul-16 8:04

I've got this the following code snippets... when compiling, I kept on getting error: implicit declaration of function. This "eeprom_memory_update_byte" came from avr/eeprom.h. What I am trying to update the atmel processor eeprom memory (not write, but to update)

In commands.c (in a function):

C++

bool Update_EEPROM_Memory_byte(byte val1, byte val2)
{
  uint8_t eepromAddr = val1;
  uint8_t eepromVal = val2;

  eeprom_memory_update_byte(eepromAddr, eepromVal);
  return 1;
}

In eeprom.h

C++

void eeprom_update_byte (uint8_t *__p, uint8_t __value);

In eeprom.c

C++

bool eeprom_memory_update_byte(uint8_t eeprom_addr, uint8_t eepromValue)
{
    eeprom_update_byte((uint8_t*) eeprom_addr, eepromValue);

    uint8_t eepromVal = eeprom_read_byte(( uint8_t *) eeprom_addr);

    if (eepromValue == eepromVal)
      return 1;
    else
      return 0;
}

please help!

Re: Trying to understand my mistake... with pointers

jeron128-Jul-16 9:30

jeron1

28-Jul-16 9:30

The first parameter in eprom_update_byte() function declaration is different than what is the the implemntation. In the .h file it is a pointer to a uint8_t (uint8_t *__p), and in the implementation it is a copy of the object (uint8_t eeprom_addr) passed by value. I'm guessing, change the implementation line in the .c file. But that might cause you to call the function differently like,
eeprom_memory_update_byte(&eepromAddr, eepromVal);

Re: Trying to understand my mistake... with pointers

leon de boer29-Jul-16 17:53

leon de boer

29-Jul-16 17:53

You haven't given us the implementation of this prototype function

void eeprom_update_byte (uint8_t *__p, uint8_t __value);

Implicit declaration error usually means you provided a prototype but no body code ... hence I am worried you haven't given me that functions code. I am assuming the EEPROM is flash and that code will do what we call the toggling test until it writes the byte to the flash. Warning if it is FLASH you usually also have to release protection registers by writing special commands to special addresses before you can write to the flash, did the original code also provide a function to release the protection on a sector per chance?

However onto your code as it stands, you are passing in the address to write as a byte which gives you a range of 0-255 in memory see here

bool Update_EEPROM_Memory_byte(byte val1, byte val2) {  // Val1 is a byte
  uint8_t eepromAddr = val1;  //  <== Really a byte as the address you can only write to memory address 0--0xff
  uint8_t eepromVal = val2;

The original function they provided had a pointer to an byte (uint_8) which will be most likely be 32 bit ... see

void eeprom_update_byte (uint8_t *__p, uint8_t __value); // First parameter is a pointer see the "*"

I suspect you need your address to be a long ..... try

bool Update_EEPROM_Memory_byte(unsigned long val1, byte val2){
  unsigned long eepromAddr = val1;  //  <== Now you can write to memory address 0-0xffffffff
  uint8_t eepromVal = val2;

Adjusted last function to take the long

bool eeprom_memory_update_byte(unsigned long eeprom_addr, uint8_t eepromValue)
{
    eeprom_update_byte((uint8_t*) eeprom_addr, eepromValue);
 
    uint8_t eepromVal = eeprom_read_byte(( uint8_t *) eeprom_addr);
 
    if (eepromValue == eepromVal)
      return 1;
    else
      return 0;
}

The alternative to an unsigned long for the address is to keep it as a pointer (uint8_t*).

That all means nothing if you have no code for the function eeprom_update_byte which isn't shown.
Other housekeeping Update_EEPROM_Memory_byte should return the result of eeprom_memory_update_byte rather than a static 1 (TRUE) result.

In vino veritas

modified 30-Jul-16 0:22am.

how to create a file input button in microsoft visual c ++ ?

jhonganteng28-Jul-16 3:46

jhonganteng

28-Jul-16 3:46

how to create buttons to input txt file and pdf files in microsoft visual c ++ ?

Re: how to create a file input button in microsoft visual c ++ ?

Richard MacCutchan28-Jul-16 4:30

28-Jul-16 4:30

Well I would start with a Windows (Win32 or MFC) application with some buttons and views on the UI, and some code behind to read the files. See theForger's Win32 API Tutorial[^] and Win32 Programming - FunctionX[^] for lots of sample code.

Help With Exception

ForNow26-Jul-16 12:47

26-Jul-16 12:47

First I would like to start thanks to all on the CodeProject I think I am getting a little better at this (this being MFC)

Well my code works fine Under the VS 2012 debugger, However When I rebuild it in Release mode. I get a message that my program stopped working with the option of invoking the VS debugger, which I do the code points to MFC code Unhandled Exception going back via the Call Stack it points to CString code Which I will gladly post,

Well the Next thing I did seeing the code works fine in Debug mode, was code a CATCH_ALL exception handler just to see if the code with go to the CATCH_ALL block in Which I invoke AfxMessageBox(".... exception handler") and the message was displayed.

I think at this point I have to get a little more specific (as to what type of exception)

So at the point I think I'll post my code The Bold underline code seems be

where the problem is when I go bank via the Call Stack In Debug mode I check the contents
and tempstr is a Valid Null Terminated String
Can someone at least point me to where I might be able find information exception to catch the specific exception that's giving me the problem

Thanks

C++

	 if(pMsg->message==WM_KEYDOWN)
    {
		TRY
		{
		if(pMsg->wParam==VK_RETURN)
		{
		//	DebugBreak();
			main_app = (CHERC_CMDApp *)AfxGetApp();
			memcpy((void *)main_app->mybaseeventptr->command,(void *)"REL",3);
          
		memcpy((void *)main_app->threadptr[curr_thread]->sockbuffer,(void *)"REL",3);
			main_app->threadptr[curr_thread]->num_buff = 3;
			CString tempstr = PSW.ia;
			tempstr.SetAt(16,0x00);
			tempstr.MakeUpper();
				if(tempstr == end_address)
			{
				memcpy((void *)main_app->threadptr[curr_thread]->sockbuffer,(void *)"TERM",4);
			main_app->threadptr[curr_thread]->num_buff = 4;
				
			}
  			::PostThreadMessage(main_app->threadptr[curr_thread]->m_nThreadID,WM_SEND_SOCK_MESS,22,(LPARAM) main_app->mybaseeventptr->command);
	
			::GetCaretPos(&mycursor);
			mychar = myedit->CharFromPos(mycursor);
			longchar = mychar;
			cursorline = myedit->LineFromChar(longchar);
			linelen = myedit->LineLength(cursorline);
			linelen = 125;
			linechar = myedit->LineIndex(cursorline);
			myedit->GetLine(cursorline,currline.GetBufferSetLength(linelen +1),linelen);
			buffptr = currline.GetBuffer(10);
			
            myeventptr = main_app->mybaseeventptr;
            strncpy((char *)myeventptr->command,(char *)&nu_lls[0],5);  // single step
			myeventptr->send_window = this;
             myeventptr->SetEvent();
		     }
         }
		 
		 CATCH_ALL(e)
		{
			AfxMessageBox("In ProgDebug  Exception Routine");
		//	DELETE_EXCEPTION(e);
		}
		END_CATCH_ALL
		 }

leon de boer26-Jul-16 17:22

leon de boer

26-Jul-16 17:22

The big difference for variables between DEBUG mode and RELEASE mode is stack variables aren't zeroed.

The simple statement

void SomeFunc (void){
int i;

}

i is guaranteed to start as zero in DEBUG mode but could be literally anything in RELEASE mode.

In the above if you need the variable to start as zero you need it.

void SomeFunc (void){
int i = 0;

}

Now you most likely have a structure or pointer variable you are assuming is zero but you have not explicitly set it in a local variable. Your code will then always work in DEBUG mode but almost never works in RELEASE mode.

In vino veritas

ForNow26-Jul-16 20:01

26-Jul-16 20:01

How about in release mode I attach the debugger I try to stepping thru the code that's giving me a problem
Thanks

leon de boer26-Jul-16 22:33

leon de boer

26-Jul-16 22:33

Also turn your error level to 4 in release mode and look for any warning along the lines possible use of uninitialized variable.

In vino veritas

Jochen Arndt26-Jul-16 21:47

Jochen Arndt

26-Jul-16 21:47

MFC throws exceptions derived from the CException class which contain additional information and provide a function to show a message.

So you may add this block of code on front of your CATCH_ALL block:

CATCH(CException, pEx)
{
    pEx->ReportError();
    pEx->Delete();
}

The operation that might fail in your code is CString::SetAt (when the position is beyond the end of the string). This will throw an exception in release builds and assert with debug builds. Because you are not getting an assertion with a debug build, the only reason for an exception in release builds can be a different (shorter) PSW.ia string. If this is not the case the exception source is probably somewhere else.

To avoid such out of range acesses you should check the length or use a function that handles them like CString::Left.

ForNow27-Jul-16 2:14

27-Jul-16 2:14

How about pEX->GetErrorMessage.....
I think ReportError is just a message box with out any information ?

Re: Help With Exception you where right !!!!!!!!

Jochen Arndt27-Jul-16 2:18

Jochen Arndt

27-Jul-16 2:18

I must confess that I have not tested if the reporting contains the error message but assumed that it would do so.

But you can of course use GetErrorMessage with your own reporting.

ForNow27-Jul-16 15:15

Re: Choosing between strings

27-Jul-16 15:15

it was the SetAt Truthfully I never called the constructer so CString tempstr(&PSW.ia,16);

Thanks

Choosing between strings

Anthony Appleyard26-Jul-16 9:47

Anthony Appleyard

26-Jul-16 9:47

Thanks for your help answering my past queries.

If I have an array of strings:-
char*sss[10];
sss[0]="cow";
sss[1]="eland";
sss[2]="kudu";
....etc....
please how in a function can I display these strings and ask the user to choose one of these strings and get the function to return the index number of the chosen string?

I could write a function from scratch; but is there such a standard library function already?

modified 26-Jul-16 17:26pm.

Richard MacCutchan26-Jul-16 21:11

Newbee Exception handling Guidance

26-Jul-16 21:11

Anthony Appleyard wrote:
is there such a standard library function

No, you will need to write your own.

ForNow25-Jul-16 4:35

25-Jul-16 4:35

Hi
I am getting an Error First Chance Exception at xxxxx (ntdll.dll) access violation reading location 0xFFFFFFFFFFFFFFFF (running under the Visual Studio Debugger)

This happens after I create a CDialog with a richedit from MAINFRAME

I don't have any exception handling in my program

When I look at the stack call its some where in NTDLL tracing back to Kernel32

Could someone at the very least point me to a good place for Exception handling for beginners in MFC

Thanks

Jochen Arndt25-Jul-16 4:57

Jochen Arndt

25-Jul-16 4:57

This might not be the expected answer:
With most types of exceptions the best handling is avoiding that they occur.

This applies especially to the access violation exception. Even when catching it by code, the only reasonable "handling" is terminating the application immediately.

In your actual case you should use the debugger stepping back in the code to find out what let the exception occur. It is probably one of your objects that hasn't been initialised or set to an error state (e.g. a pointer containing the value -1) and the exception is thrown when it is used the first time (inside the kernel / ntddl in your case).

A general hint to reduce debugging time searching for the source of such exceptions is checking the success state of every function that provides one (usually the return value). The simplest way to do this is using assertions in debug build. With MFC you can use the ASSERT (MFC)[^] and VERIFY[^] macros.

ForNow25-Jul-16 5:31

25-Jul-16 5:31

Actually that was the answer I was hoping for

I'll back track and look
At what happened right before

Thanks

Richard MacCutchan25-Jul-16 5:12

25-Jul-16 5:12

First Chance Exceptions can be benign under the debugger. Did the application crash at that point? If so, you should look at the stack trace to see what was the last line of code in your application.

ForNow25-Jul-16 5:30