C / C++ / MFC

No you don't ... think about it and just rewrite what it expands to This is what you have typedef unsigned char BYTE; void hex_to_ascii(BYTE *ipx, char *str, int num); // forward declaration #define BYTE char void hex_to_ascii(BYTE *ipx, char *str, int num) { }; Expanded removing BYTE and replacing the type that is in scope it becomes ... dead simple Remember the macro is in the preprocessor which is why it always expands like this, and why the second BYTE is gone by compile time. The first BYTE remains (it is prior to the macro definition), and I strike it out and changed it to it's proper type. void hex_to_ascii( (BYTE) unsigned char *ipx, char *str, int num); // forward declaration void hex_to_ascii(char *ipx, char *str, int num) { }; Get it your forward prototype and function body no longer match. Depending on the C compiler it can see it as 1.) Two different functions with the same name .. THAT IS AN ERROR 2.) The same function with mismatched or redefined types ... THAT IS AN ERROR Which depends how good your compiler is and there is no standard answer to what it will say. It even depends if they are in the same files or not because the compiler is trying to guess what you are meaning to do. His example complicates it because he has an extern in a 3rd file which I think means the compiler doesn't have a clue whats going on it's got 3 prototypes probably only 2 matching. As I said you are arguing about something that is easy to test and I have seen many times when joining multiple libraries together. In vino veritas

That is why I chosen to do m_pMyDialog as member variable, and everything it's all right now. Thank you all of you !

No multiple Repost in multiple forums, Please. Patrice “Everything should be made as simple as possible, but no simpler.” Albert Einstein

they arent, so you are OK.

I am confused what Jochen is saying to you but I will say nothing you nor Jochen have code will make the items within the array volatile. First lets cover the basics volatile is an optimizer instruction it has very little to do with the C language as such it is also HIGHLY vendor sensitive. So the first thing you always need to do is check your vendor tools and specification. My next warning is to always put the volatile between the type and the name not at the front as people love to do. Things like the arm compilers are notorious with volatile in the front of the type and if you use it in macros you will end up with it on the wrong thing. I covered this in a recent article on baremetal with the RPi but Arm covers this in there documentation ARM Information Center[^] You see the format, that is not just the arm standard it is the standard I suggest you use as most embedded compilers get it right type volatile * const ptr; | | | | | | | | | +------> ptr is a | | | +-----------> constant | | +---------------> pointer to a | +---------------------> volatile +---------------------------> integer/long/etc Almost all vendor tools will fail to do with volatile what the full C specification says because the specification isn't written by embedded processor vendors and they get little say in it. Some of the junk that is in the C specification around the word volatile is ignored because it doesn't make sense in micro-controllers. The scary stat is 96% of vendor tools fail the full C implementation (Testing result reference :[^]) So lets get down to specifics the volatile must also be on any item within the array putting a volatile on the array itself will not work almost any compiler. The compiler doesn't see "blocks" of things as volatile it only sees things it is accessing in the mode it is accessing them as volatile. The fact you want a volatile inside a malloc would tend to indicate you are playing around with a DMA controller so I will reference hardware access here. If this is just shared multitask memory nothing changes it's just simp

If you want your item to be highlighted (blue) it must not only be selected, but the containing control must have the focus. Read up on "set focus". Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012

Here is the solution in details: There is a discrepancy with the actual function and the header file. That's Microsoft's mistake which due to be fixed. 1. Go to MAPIUtil.h where OpenStreamOnFile is declared. Change __in LPCTSTR lpszFileName, to __in_opt LPCSTR lpszPrefix, 2. Use ASCII file name when calling OpenStreamOnFile - Michael Haephrati מיכאל האפרתי

The only way to provoke a compiler error would be to pass the knowledge of the full list of class properties to the compiler, at compile time. That would defeat the purpose of a generic class definition, and you could just as well define simple member variables instead. This raises the question: where do your requirements come from, i. e the two requirements to define a generic class, and to force compile time errors when accessing an incorrectly labeled property? One of them has to go. GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

We do not do your HomeWork. HomeWork is not set to test your skills at begging other people to do your work, it is set to make you think and to help your teacher to check your understanding of the courses you have taken and also the problems you have at applying them. Any failure of you will help your teacher spot your weaknesses and set remedial actions. So, give it a try, reread your lessons and start working. If you are stuck on a specific problem, show your code and explain this exact problem, we might help. Patrice “Everything should be made as simple as possible, but no simpler.” Albert Einstein

Still struggling with the issue Here is exact syntax I have used - it suppose to "print" , I assume substitute, the libraries in package ( opencv ) to the linker as -l options. It does not matter if the options are --libs opencv or opencv --libs - which is expected. "$(pkg-config opencv --libs)" Here is partial liker output make all Building target: TEST_1 Invoking: GCC C++ Linker g++: error: missing argument to ‘-l’ g++ -L/usr/local/lib -o "TEST_1" ./src/TEST_1.o -l"" make: *** [TEST_1] Error 1 makefile:45: recipe for target 'TEST_1' failed I have tried different format / syntax and "$(command)" is correct per the link you have provided. From the output it is notable that no -l files were included - -l"". I do not know what else can be wrong. The command does not expands to anything linker can use and it should look as terminal output. jim-desktop:~$ pkg-config opencv --libs -L/usr/local/lib -lopencv_shape -lopencv_stitching -lopencv_objdetect -lopencv_superres -lopencv_videostab -lopencv_calib3d -lopencv_features2d -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_video -lopencv_photo -lopencv_ml -lopencv_imgproc -lopencv_flann -lopencv_viz -lopencv_core I have asked in several forums and all I am getting is how to add -L/-l options MANUALLY to the linker options. BTW including ":" before the manually inserted file name specifies to the pkg-config to use library file WITHOUT using the file extension. Nice to know but does not solve my issue. Cheers Vaclav

We have articles on this topic: 2d game[^].

Just ask OpenMP how many processors it is using int omp_get_num_procs(); If you want the answer from windows SYSTEM_INFO sysinfo; GetSystemInfo(&sysinfo); int countCPU = sysinfo.dwNumberOfProcessors; If you are expecting it to make MFC itself quicker it won't by very much at all unless it's just particular things like graphics or file access that is slowing you down. To explain why we need to look at MFC which is an event drive system, meaning it fetches messages and dispatches messages that is it's basic behaviour. Part of that behaviour is it needs the events to process in the order they are in the message queue. For example clicking on the X close button on the top of an application fires off 3 messages WM_CLOSE WM_DESTROY WM_QUIT Those messages must be processed in that order and the next message can not be started to process until the one before it is completed. So the required ordering of processing of the event queue trumps any multiprocessor threading you want to put on the message queue. Even things like WM_PAINT messages are in order you must paint the windows in that order. It's pretty safe to say most things in the message queue except probably things like WM_MOUSEMOVE are going to have a required order to them and multithreaded or not you can't process the next message without the previous completing. So you can't really speed the MFC message framework up. The things you can speed up is the single processing of a single message. So in response to a WM_XXXXXXX message you may spawn threads to achieve the required task that is to be executed on that message in a faster time. If what you are doing is safe to windows it is safe to MFC because your threads will all end at exactly the same point as a single threaded program and you will either send back a LRESULT, Send/Post off a message or do some action and MFC would be unaware of the threads. So basically if you multithread within a single message process or within an action or process that is called you can do it safely from MFC point of view and in fact MFC would be oblivious to the threading. If you are having problems and crashing you are either not containing yourself to those guidelines and creating order problems for MFC or alternatively what you are doing is just broken on windows and the problem has nothing to do with MFC. You can split an join threads just using C++11, make a windows console application and paste this code in to see that and mutexing stuff to control. Your OpenMP etc should gi

The arrow keys allow moving from one check box to another. If you don't want this behaviour use the resource editor to set the group property of the corresponding check boxes and the following control in the tab order. If you want to use conditions within the RC file you have to pass them using build options because the definitions used when compiling are not passed when processing RC files. Similar has just been asked a few threads below: #ifdef...#endif is not working in Resource(.rc) file - C / C++ / MFC Discussion Boards[^] See this answer: Re: #ifdef...#endif is not working in Resource(.rc) file - C / C++ / MFC Discussion Boards[^]

thank you very much I would try and test it.

Yes, it does. bManual = FALSE means that it is an Automatic ResetEvent after a wait operation. Cheers, Mick ------------------------------------------------ It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.

Looking at the site, the package it already does that via it's viewer (open3mod). They call it a "screenshot" although more technically it is a render. They are inserting a camera position against the 3D model in a 3D space and rendering what would be seen. You would have to do the same.