C / C++ / MFC

well OK it is illegal i wont try it., i mean i only wanted it so i can make an app that will allow you to make a type of AI afk non competitive grinder bot follow path so people can do long distince routs without having to be the PC for long time. i guess i should just start on a auto clicker and do even more research

C++ for scan image - Google Search[^]

If the computer has .NET 4.5 or later installed, that registry key exists regardless of the OS version: How to: Determine which .NET Framework versions are installed | Microsoft Docs[^] "These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

I think I may have stumbled onto the answer. Seems ADO may not be able to handle parameterized SQL statements since I can pass currency values to a stored procedure call. Thank you for your time in replying to question. Please close the question.

boost::bind returns a function object, not a C function. It may behave like a function pointer, but these types are different, and the compiler won't be able to match the function argument list with a function object as the second argument. The problem you describe cannot be solved with the limitations you've set. Clearly, part of the limitations are of your own making and need to be revised. To understand that, you just need to think about the flow of control: 1. from your code you set up a callback mechanism that is supposed to call your callback function 2. then you call a function outside of your code 3. At some point this outside function calls your callback function, passing along some data 4. Your callback function is called. the only data it has are the function arguments it got passed from it's calling function. At this point it is entirely out of context from the rest of your application and doesn't know about any of your B objects that you may have created. If the calling function doesn't know about Bs, then the callback function cannot know about them either. It is impossible to process anything dependend on some B member variables in the callback function, unless you pass these variables all the way from step 1 through step 4! Unfortunately the code in step 3 is outside your control - therefore this is impossible. Or it wouldbe impossible if you insist on passing along a reference to some B object: the caller doesn't know about that class! There are only two solutions that may work: 1. the library you are using lets you pass along additional data to the callback setup which then will be passed to the callback invocation. If so, you could just pass along the values of var1 and var2. 2. If the above isn't possible, the only alternative I see is to use global variables to store the state of B or just its member variables. Of course. the premise that your callback absolutely needs to know your B object may have been wrong! Time to think about how you intended to use this callback mechanism! 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)

You have the code so look at what messages a CDialog sends and posts in response to it's WM_CLOSE and WM_DESTROY. In vino veritas

You are welcome.

I have solved, I have used the same image list handle for two controls, CTreeCtrl and CListCtrl ... and I haven't share this image list correctly ... now everything is alright.

Thank you.

My app is MFC, yes. Found out that snap functionality works only with CFrameWnd inherited windows and not with CDockablePane, as they do not have a DWM caption bar.

Quote: it "requests" the compiler to put it inline but the compiler was not required to do so and it was up to the compiler to decide. That and more than that. See the documentation (inline specifier - cppreference.com[^]) for the gory details.

For maths, numerical recipes and wolfram is always the goto GitHub - sasamil/Quartic: Solving algebric equation of 4th order. Fast and efficient. C++ implementation.[^] Read the docx file to understand it but it sort of follow this form Math Forum - Ask Dr. Math[^] The code isn't great like returning an allocated memory block ... I would rework it. You can solve them online on wolfram .. try an example like solve x^4 + 12*x^3 + 7*x^2 + 2*x + 12 = 0 https://www.wolframalpha.com/input/?i=solve+x%5E4+%2B+12*x%5E3+%2B+7*x%5E2+%2B+2*x+%2B+12+%3D+0[^] It's useful to check your code In vino veritas

Really for the OP but I will put here to follow the discussion Someone is on a multicore processor and the streams which are buffering are on different cores with resource locks :-) This is generally not guaranteed to give the expected order printf("Expect 1\n"); perror("Expect 2\n"); printf("Expect 3\n"); Simply put two independent streams are not guaranteed to synchronize without you forcing the issue. In the above Expect1 will always be before Expect3 but Expect2 can be before, in the middle or after those two lines. sync_with_stdio() if implemented will work but it implies a heavy overhead on a many multicore situation which is why it might be off. I think it is supposed to default on with some c++ versions (but on multicore it is often violated because it is horrific) you would need to check with your compiler. The simple answer is stop using perror and simply just use one stream aka printf/cout, flush after each print or put lock primitives in the order to guarantee the order. It is easily avoidable ... so avoid it :-) In vino veritas

I explained how in my earlier message.

Thanks Richard and Victor for the consolations. This is a much nicer forum than some. I do try to research before posting but sometimes without help I get stumped.

Cause you have to reprogram a lot of code with the CUDA, and our program is already parallelized with the OpenMP.

The overriding concept of makefiles is the ability to specify the dependencies in a simple tree. But since you are the one who knows which module(s) depend on which, you are the person who will need to create the tree.

:)

I am not a real fan of MFC but I can tell you what windows API is doing. Dialog backgrounds paint by WM_CTLCOLORDLG, WM_CTLCOLORSTATIC it used to be WM_CTLCOLOR and I suspect MFC still uses WM_CTLCOLOR because it has a couple of bugs. Usually what you want to do is return a NULL_BRUSH with GetStockObject(NULL_BRUSH); So this one if you paint the entire dialog then return a NULL_BRUSH WM_CTLCOLORDLG message - Windows applications | Microsoft Docs[^] MFC may use this one and again return a NULL_BRUSH WM_CTLCOLOR message - Windows applications | Microsoft Docs[^] That means it doesn't paint the background before it sends you an WM_PAINT :-) If you want/need to transparent overlay the bitmap you have to use a transparent colour to stop flashing void CDemoDialog::OnPaint() { CPaintDC dc(this); // device context for painting // transfer the bitmap into paint DC using a transparent color dc.TransparentBlt( 10, 10, bmp.bmWidth, bmp.bmHeight, // destination coordinates and sizes &pDCTmp, // source DC .. your DC with bitmap 0, 0, bmp.bmWidth, bmp.bmHeight, // source coordinates and sizes RGB(255, 0, 0)); // transparent color } In vino veritas