C / C++ / MFC

Mur2501 wrote: When I made a separate class file in code blocks... Doesn't Code Blocks (the IDE) have a forum? "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

I apologize I had the wrong dialog identifier thus the wrong dialog control

I edited it after reading to make it more easy to understand. I have seen that the old video card is not very good improving the performance of the CPU.

leon de boer wrote: No David its a Modeless dialog pressing the Ok button doesn't close the dialog like on a normal modal dialog. As long as that method calls DestroyWindow() rather than CDialog::OnOK() (which internally calls CDialog::EndDialog()), the dialog will close just fine. leon de boer wrote: He is probably going to put some other button on screen to exit but its a stock standard modeless dialog. There is no standard that dictates what UI element is used to close a modeless dialog. It could be Esc, the "X", Alt+F4, or a Cancel/Close button. Instead, it's what the code behind those elements do that's important. I'm well aware of how modal and modeless dialogs behave. My question was not because I wanted to know the answer to something; it was instead asked to make the OP reconsider his design. Clicking the "X" button should call OnCancel() method. "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

I don't need proof I know you are right thanks for explaining :)

With not dialog based applications you should derive your view class from CListView Class[^]. That can then be populated with the recordsets using the CListView::GetListCtrl[^] function to get a reference to the list control. The OnInitDialog() corresponding function for views is CView::OnInitialUpdate[^]. See also the example code at the GetListCtrl() link.

Another difference to consider is their behavior. For an interpreted language, the program is run line-by-line when you request it to run. If there is a problem in the logic or any other 'bad things', it will run until it hits one. Thus, if you misspelled a variable's name it wouldn't react to it until you run it and it happens to come across the misspelled version. Also, if you left out a BEGIN or END statements, it would run until that caused a problem, if ever. Some feel that these languages are easier for beginners to start with because they're not all-or-nothing, but not everyone agrees with that. Now, for a compiled language, the entire program is converted to 'machine code' (often in several steps). This code has to take the entire program into consideration at once. If you have a problem it will not be able to figure out what to do and you'll get an error. The program will NOT be compiled. A misspelled variable is 'undefined' and would be a problem. Similarly, the compiler will look for an END for every BEGIN, in the correct order or it will be an error. Compiling a program is an all-or-nothing affair. Because of this difference in when the program is turned into real computer instructions, the interpreted languages are much slower than compiled languages when running. "The difference between genius and stupidity is that genius has its limits." - Albert Einstein "As far as we know, our computer has never had an undetected error." - Weisert "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010

The _T is a macro provided by TCHAR.H for unicode/multilingual support. If you go to the project settings->general tab->Character set you will have that to "not set" setting. That macro allows you to use the other choices being unicode and multi-byte character sets making your code work multilingual like in chineese windows. For you in ascii mode the macro actually does nothing (which you worked out) but if you select the other modes you will see you will get an error on every static text the _T tells the compiler to make the string in the correct mode and removes the error. Being a commercial programmer and as Microsoft has made it so easy for doing it we generally try and use the multilingual code calls since Visual Studio 2013. This became almost compulsory when trying to write true 64 bit applications. The default setting of an empty project is actually to set for unicode character set. Essentially TCHAR becomes a replacement for the standard char and its size varies in the compilation modes. They provide new string functions that match the old string functions in TCHAR.H but have different code for the different modes. Lets give you an example strlen becomes _tcslen those calls work identical the difference being _tcslen will work in any language mode compilation, while strlen will only work in language "not set" mode like you have. Here is the link to what is going on from MSDN strlen, wcslen, _mbslen, _mbslen_l, _mbstrlen, _mbstrlen_l[^] This code is designed specifically for windows (it uses the Win32 API), it is not general in nature like that could work on linux so there is no reason to write generically but we should try and cover the different modes of windows compilation, especially as it is easy. So for me the changes are just habit. There is a funny part of this that so many of us are writing in that style that the linux community is having issues trying to port our code. So if writing general code I would probably try to avoid this style of programming. In vino veritas

The "official" way to do expression evaluation involves parse trees and reverse Polish notation, but I found a simpler more practical approach: Repeatedly process your list of tokens, making it one step simpler each time by applying a series of rules: 1. If you see the sequence '(', 'number', ')', replace it with just 'number'. 2. For each operator in decreasing precedence, look for the sequence 'number', 'operator', 'number' and replace it with the result of the operation. If you end up with a single number, that's your answer. Anything else indicates a syntax error in the input expression.

Compiler Problems Can't Locate the Compiler:- On UNIX systems, you may see the following error message if your path isn't set properly: javac: Command not found Use setenv or a similar command to modify your PATH environment variable so that it includes the directory where the Java compiler lives. Syntax Errors:- If you mistype part of a program, the compiler may issue a syntax error. The message usually displays the type of the error, the line number where the error was detected, the code on that line, and the position of the error within the code. Here's an error caused by omitting a semicolon (;) at the end of a statement: testing.java:14: `;' expected. System.out.println("Input has " + count + " chars.") ^ 1 error Sometimes the compiler can't guess your intent and prints a confusing error message or multiple error messages if the error cascades over several lines. For example, the following code snippet omits a semicolon (;) from the bold line: while (System.in.read() != -1) count++ System.out.println("Input has " + count + " chars."); When processing this code, the compiler issues two error messages: testing.java:13: Invalid type expression. count++ ^ testing.java:14: Invalid declaration. System.out.println("Input has " + count + " chars."); ^ 2 errors The compiler issues two error messages because after it processes count++, the compiler's state indicates that it's in the middle of an expression. Without the semicolon, the compiler has no way of knowing that the statement is complete. If you see any compiler errors, then your program did not successfully compile, and the compiler did not create a .class file. Carefully verify the program, fix any errors that you detect, and try again. Semantic Errors:- In addition to verifying that your program is syntactically correct, the compiler checks for other basic correctness. For example, the compiler warns you each time you use a variable that has not been initialized: testing.java:13: Variable count may not have been initialized. count++ ^ testing.java:14: Variable count may not have been initialized. System.out.println("Input has " + count + " chars."); ^ 2 errors bikram singh majithia

The WriteFile doesn't need or require an overlapped access and I would be intrigued what security attributes you are feeding in via sa. Naming the event is fine but why are you needing to provide specific security attributes are you doing something special? The worry I gleaned was you hold the event handle in sysblk.mail are you remembering to copy the handle reference into your overlapped structure? It's sort of odd what you are doing there but not wrong so long as you remember to transfer the handle. The usual read thread code direct from MSDN looks like char buffer[100]; OVERLAPPED ovlp = {0}; // Create event in overlapped structure // This directly places Event handle in empty Overlapped structure ovlp.hEvent = CreateEvent(NULL, false, false, NULL); if (ovlp.hEvent == NULL) { // You have some error creating the event run some error code } DWORD read; do { ReadFile(mailslot, buffer, sizeof(buffer), &read, &ovlp); // ovlp.handle in your case must be sysblk.mail buffer\[read\] = 0; WaitForSingleObject(ovlp.hEvent, INFINITE); // you are then waiting on your event sysblk.mail process\_message(buffer); } while (strcmp(buffer, "exit")); // <= Your exit thread condition The write thread is create function is non overlapped HANDLE mailslot = CreateFile("\\\\.\\mailslot\\myslot", GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, 0, NULL); They are the by the book MSDN examples and your code should be some extension of that process inside your sysblk code. Also remember this sort of thing is for relatively low speed, small packet exchanges if you want to go beyond that you need to change to memory mapped files. In vino veritas

I searched hither and yon but I was finally able to find these references for you: ;) Ribbon Designer (MFC)[^] CMFCRibbonBar Class[^] Walkthrough: Creating a Ribbon Application By Using MFC[^] Your First MFC C++ Ribbon Application with Visual Studio 2010 - Pete Brown's 10rem.net[^] "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

How to solve circular dependency in linker is shown here Library order in static linking - Eli Bendersky's website[^] The trick is to organize the library files as shown and link them twice which is perfectly valid. I assume that is the reason you are trying to avoid including the library file. In vino veritas

Sorry but this site does not provide code to order. You need to be more specific about the help you need.

Open the file with OPEN_ALWAYS and check the error code to know if it has been created or an existing file has been opened: // Clear error SetLastError(0); HANDLE hFile = CreateFile(fileName, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile != INVALID_HANDLE_VALUE) { if (GetLastError() == ERROR_ALREADY_EXISTS) { // Read file here } else { // Ask for key and write file here } CloseHandle(hFile); } Alternatively check if the file exists and open it for reading or writing afterwards. This can be optimised by trying to open the file for reading and if that fails to open it for writing: HANDLE hFile = CreateFile(fileName, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile != INVALID_HANDLE_VALUE) { // Read file here } else { hFile = CreateFile(fileName, GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile != INVALID_HANDLE_VALUE) { // Ask for key and write file here } } if (hFile != INVALID_HANDLE_VALUE) CloseHandle(hFile);

This depends on the content stored in the byte array. Because the function expects a NULL terminated string, the byte array must contain such a string. You must also know the text encoding for the stored string. Assuming your byte array contains an ASCII or ANSI string, you can call _strlwr: _strlwr((char *)byteArray); The casting to char * avoids compiler warnings or errors because BYTE is unsigned (unsigned char). If the resulting string must be printed out later with Unicode builds, convert it using the MultiByteToWideChar function (Windows)[^]. If it is ASCII or uses the current code page of the user running the application, it can be also converting by assigning the lowered string to a CString: CString strLwr = _strlwr((char *)byteArray); The above will work for Unicode and multi byte builds (with Unicode builds, the string is converted to Unicode).

Thanks.

The only thing I can see change between the two modes is the delay // COMBINED MODE 1 & 2 CODE FROM WHAT YOU GAVE int led = 13; int mode = 1; // Set mode 1 start static int delay1[2] = {500, 0}; // 500ms delay for mode 1, 0 ms delay for mode 2 static int delay2[2] = {500, 5000}; // 500ms delay for mode 1, 5000 ms delay for mode 2 void setup() { pinMode(led, OUTPUT); } void loop() { digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level) delay(delay1[mode-1]); // wait depending on mode .. dont forget arrays start at zero in c digitalWrite(led, LOW); // turn the LED off by making the voltage LOW delay(delay2[mode-1]); // wait depending on mode .. dont forget arrays start at zero in c // this is just to show off both modes usually something does this change // this code simple forces alternation between the 2 modes if (mode == 1) mode = 2; else mode = 1; } In vino veritas

A probable error source is szBuf being NULL.