using MFC and casablanca....

Nov 24, 2014 at 7:50 PM
Can anyone point me to a really good tutorial or example of using casablanca with MFC? I just have soo many questions on how to send a request using the pplx tasks. Sometimes it's best just to see a working example. The casablanca samples all appear to use the task_continuation_contex which would be lovely to use, but appears to only work for Windows store apps, or so the documentation suggests? I have read all the suggested readings, online blog ppl experts and lots of stackoverflow questions but nothing seems to give me a clear answer on how to really use MFC and Casablanca together.

1) is there any way to join the main thread when the response is recieved for an MFC gui.

2) There are some blogs that suggest that you can provide a std::function callback to the pplx task to call when it is complete but I can't see how this would work unless the task is continued on the main thread?

3) There is some talk about marshalling data to the main thread, so I could provide the json response to the main thread for consumption this way but again an example of this would be very helpful.

4) If I do need to marshall data to the main thread and have the main thread periodically check for new data, has anyone used Boost interprocess for this? I am using it for other areas of the code and I thought perhaps this would make my life simplier if I can just reuse the same libraries for shared memory. Other suggestions would be welcome?!

In the end what I want to do is have some MFC GUIs remain responsive when a request is sent. The requests may take a little time for the response so blocking the main thread until a response is returned is not acceptable. Preferably when the response returns I would like to rejoin the main thread and call a callback to process the response (I don't use the word process here lightly as it may be a much more complex algorithm then simply post a string in a text box in the gui). With that said I will do whatever works with MFC and is the simpliest code to maintain and debug.

I am by no means a REST expert, I am very new to casablanca so any help would be greatly appreciated,
Nov 26, 2014 at 12:05 AM
Hi, i think this s very important. i hope other people who could advise us about MFc and casablanca will respond this
i need to study about this too
Nov 28, 2014 at 8:39 PM
Thanks for joining the discussion Tirat, it’s good to know others are wondering the same question as it means I haven’t missed something too obvious.

I just wanted to add and update, that as far as I can tell this will just not work with a continue in the ui for MFC.

Since there were no solutions provided, I have gone ahead to pursue communication between the two threads.

After a little more research I realized boost interprocess is not thread safe so that was a dead end for me.
It has been decided to move forward with just a class which encapsulates the std::mutex and std::conditional_variable. There are a few good examples on stackoverflow for this kind of implementation which appears to be pretty standard thread to thread communication, (I think because I was doing much of my research looking for information on “tasks” I missed a lot of good info on how to communicate between threads which is what this has really come down too now).

I think if I had more time and I were more adventurous I might try boost signals 2 which looks like it adds some convenience and apparently is thread safe. (note that boost signals is not thread safe so you have to be sure you are using boost signals “2”).

Anyway I just wanted to provide a little feedback in case others are also having this problem, just like me and Tirat.

Any solution or information on this topic would still be greatly appreciated.
Nov 28, 2014 at 10:33 PM
Actually, I have successfully used Casablanca within an MFC application. Yes, there is a problem with the two systems in one application. I can’t prove it, but I think has to with the memory models and those models as used in threads. It has something to do with the fact MFC and strict Win32 windows are incompatible. As we who build MFC apps know that windows.h and afx headers are incompatible at compile time and the different libs are incompatible at link time.

The work around is this. You have to combine the two at run time. Put all of the Casablanca code and libs into a dll with an interface that you can use to accomplish whatever it is that you need to do and load that dll using the LoadLibrary command. You can extract all the functions at run time and call them. If you try to link the dll at link time using a .lib you will fail.

If there is sufficient desire I can point you to some code examples of loading dlls at runtime.

One thing, passing data across the dll boundary and the main thread can be dicey. Data transfer is somewhat limited. Pointers in the separate threads are sometimes not valid in the other (segmentation fault). If you pass in a pointer and and you expect to write to the location pointed to, you will have problems.You will not be able to pass Casablanca datatypes into the main thread, nor MFC types the other way. You have to use data types know in both worlds.

Dec 3, 2014 at 6:35 PM
The C++ Rest SDK has no built in knowledge about MFC. So you are correct if you need to update something on the UI you would have to handle in the same way as if you had done so from any other worker thread. This would be the same for any other UI framework that the library doesn't know about.

The task_continuation_context in PPL is specifically only for Windows store applications.