After some experimentation, there are a few recommendations that I feel comfortable making.
- the
concurrency task functionality is easier to use than C++11 std:thread and is more flexible in using with coroutines however std::async is easier to use than std::thread and works with co_await as well
- coroutines using
co_await look to be a great addition with concurrency when using C++/WinRT and the Async type functions in WinRT (see C++ Coroutines: Understanding operator co_await for a technical explanation)
- you can make your own async functions using the
concurrency::task<> template as the return type of the function or use concurrency::create_task() and you can use co_await with such a task
- you can also use
co_await with std::async() since std::async() returns a std::future<> which has an Awaitable interface (see await/yield: C++ coroutines though it is dated Nov-2016)
- you can also use
co_await with a std::future<> as provided by the get_future() method of a std::packaged_task<> ( see also What is the difference between packaged_task and async )
- you can make generator functions using
std::experimental::generator<type> as a function return type along with the co_yield operator to return a value of the specified type in the generated series
- to update the MFC UI requires that any code runs in the MFC UI thread the MFC object was created so Windows messages are needed to communicate with the MFC windows and window class objects from other threads or you must switch the thread context/affinity to the UI thread context for that object
winrt::apartment_context can be used to capture the current thread context and later resumed using co_await which may be used to capture the main UI thread context to be reused later (see Programming with thread affinity in mind in the article Concurrency and asynchronous operations with C++/WinRT)co_await winrt::resume_background(); can be used to push the current thread's context to a background thread which can be useful for a lengthy task that may be in the main UI thread context and you want to make sure that it is not- when sending messages to a window, make sure that the window actually has been created and exists, during application startup the application must create windows before you can use them; just because the MFC class exists does not mean the underlying window has been created yet
::SendMessage() is synchronous in which the message is sent and a response is returned::PostMessage() is asynchronous in which the message is sent and a response is not returned- using
::PostMessage() be careful that pointers sent in messages do not go out of scope before the receiver uses them as there is typically a delay between when ::PostMessage() returns and the message handle receiving the message actually does something with the message
- probably the most straightforward approach is to use the
ON_MESSAGE() macro in the message map with a message handler interface of afx_msg LRESULT OnMessageThing(WPARAM, LPARAM)
- you can use Windows message identifiers in the space beginning with the defined constant of
WM_APP and the same identifier can be used in different classes
- you can use much of C++/WinRT quite easily with MFC with just a bit of care though admittedly I only have tried a few things and there are some limitations such as not using XAML according to the documentation
- if you do use C++/WinRT within an MFC application, you are limiting your application to versions of Windows that has the Windows Runtime which pretty much means Windows 10 (this rules out using C++/WinRT with Windows 7, POS Ready 7, etc.)
- using C++/WinRT requires adding compiler option
/stdc++17 to enable the ISO C++17 Standard for the C++ Language Standard and using coroutines requires the /await compiler option
Here are a view resources.
Microsoft Build 2018
Effective C++/WinRT for UWP and Win32
May 06, 2018 at 3:27PM by Brent Rector, Kenny Kerr
CppCon 2017: Scott Jones & Kenny Kerr
C++/WinRT and the Future of C++ on Windows
Published on Nov 2, 2017
Using Visual Studio 2017 Community edition, I created a new MFC Single Document Interface (SDI) project using the Visual Studio style. After the application comes up, it looks like the following image.
![screen shot of MFC app in Visual Studio theme]()
Helper functions for messages
The first change I made was to provide a way to send a Windows message to one of the panes (ClassView or OutputWindow) that I would like to update. Since the CMainFrame class in MainFrm.h had the MFC objects for these windows as in:
protected: // control bar embedded members
CMFCMenuBar m_wndMenuBar;
CMFCToolBar m_wndToolBar;
CMFCStatusBar m_wndStatusBar;
CMFCToolBarImages m_UserImages;
CFileView m_wndFileView;
CClassView m_wndClassView;
COutputWnd m_wndOutput;
CPropertiesWnd m_wndProperties;
I modified the class to provide a way to send a message to these windows. I chose to use SendMessage() rather than PostMessage() to eliminate the pointer going out of scope issue. The concurrency class works fine with SendMessage().
LRESULT SendMessageToFileView(UINT msgId, WPARAM wParam, LPARAM lParam) { return m_wndFileView.SendMessage(msgId, wParam, lParam); }
LRESULT SendMessageToClassView(UINT msgId, WPARAM wParam, LPARAM lParam) { return m_wndClassView.SendMessage(msgId, wParam, lParam); }
LRESULT SendMessageToOutputWnd(UINT msgId, WPARAM wParam, LPARAM lParam) { return m_wndOutput.SendMessage(msgId, wParam, lParam); }
These are the raw, bare infrastructure for sending the messages to update the various MFC windows. I put these into CMainFrame class as that is a central point and the AfxGetMainWnd() function allows me to access the object of that class at any place within the MFC application. Additional classes to wrap these raw functions would be appropriate.
I then put message handlers into each of the classes within the BEGIN_MESSAGE_MAP and the END_MESSAGE_MAP macros. The output window update was the easiest and simplest and look like:
BEGIN_MESSAGE_MAP(COutputWnd, CDockablePane)
ON_WM_CREATE()
ON_WM_SIZE()
// ADD_ON: message handler for the WM_APP message containing an index as
// to which output window to write to along with a pointer to the
// text string to write.
// this->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)_T("some text"));
ON_MESSAGE(WM_APP, OnAddItemsToPane)
END_MESSAGE_MAP()
with the message handler looking like:
// ADD_ON: message handler for the WM_APP message containing an array of the
// struct ItemToInsert above. Uses method AddItemsToPane().
LRESULT COutputWnd::OnAddItemsToPane(WPARAM wParam, LPARAM lParam)
{
switch (wParam) {
case OutputBuild:
m_wndOutputBuild.AddString((TCHAR *)lParam);
break;
case OutputDebug:
m_wndOutputDebug.AddString((TCHAR *)lParam);
break;
case OutputFind:
m_wndOutputFind.AddString((TCHAR *)lParam);
break;
}
return 0;
}
I added the method prototype to the class along with this enumeration to make the functionality a bit easier to use.
enum WindowList { OutputBuild = 1, OutputDebug = 2, OutputFind = 3 };
With the above changes I was able to insert into the message handler for "New" in BOOL CMFCAppWinRTDoc::OnNewDocument() the following code to put a text string into the "Build" Output Window:
CMainFrame *p = dynamic_cast <CMainFrame *> (AfxGetMainWnd());
if (p) {
p->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)_T("this is a test from OnNewDocument()."));
}
Using C++/WinRT with MFC and concurrency
To test this along with testing using C++/WinRT with MFC, I added the following concurrency task to CMainFrame::OnCreate() which is called when the application is starting up. This source spins off a task which then uses the Syndication functionality of C++/WinRT to fetch an RSS feed list and displays the titles in the OutputWindow pane labeled "Build" as seen in the screen shot above.
concurrency::create_task([this]() {
winrt::init_apartment();
Sleep(5000);
winrt::Windows::Foundation::Uri uri(L"http://kennykerr.ca/feed");
winrt::Windows::Web::Syndication::SyndicationClient client;
winrt::Windows::Web::Syndication::SyndicationFeed feed = client.RetrieveFeedAsync(uri).get();
for (winrt::Windows::Web::Syndication::SyndicationItem item : feed.Items())
{
winrt::hstring title = item.Title().Text();
this->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)title.c_str()); // print a string to an output window in the output pane.
}
winrt::uninit_apartment();
});
To use the concurrency and the C++/WinRT functionality I had to add a couple of include files near the top of MainFrm.c source file.
// ADD_ON: include files for using the concurrency namespace.
#include <experimental\resumable>
#include <pplawait.h>
#pragma comment(lib, "windowsapp")
#include "winrt/Windows.Foundation.h"
#include "winrt/Windows.Web.Syndication.h"
In addition, I had to modify the Properties of the solution to specify C++17 and an additional compiler option of /await which are marked with blue arrows in the screen shot below.
![screen shot of Visual Studio solution properties showing changes]()
Using co_await with MFC and C++/WinRT
From a helpful comment from @IInspectable I took a look at coroutines with Visual Studio 2017 and MFC. I have been curious about them however it seemed that I could not come up with anything that would compile without errors from using co_await.
However starting with a link in the comment from @IInspectable I found a link to this YouTube video, CppCon 2016: Kenny Kerr & James McNellis “Putting Coroutines to Work with the Windows Runtime", which had a source code sample around time 10:28 that finally I was able to come up with something that would compile and work.
I created the following function which I then used to replace the above source with concurrency::create_task() and the lambda with a function call to the following function. The function call was simple, myTaskMain(this); replacing the concurrency::create_task([this]() { lambda in the int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) method and then adding the following source code above the OnCreate() function body.
winrt::Windows::Foundation::IAsyncAction myTaskMain(CMainFrame *p)
{
winrt::Windows::Foundation::Uri uri(L"http://kennykerr.ca/feed");
winrt::Windows::Web::Syndication::SyndicationClient client;
winrt::Windows::Web::Syndication::SyndicationFeed feed = co_await client.RetrieveFeedAsync(uri);
Sleep(5000);
for (winrt::Windows::Web::Syndication::SyndicationItem item : feed.Items())
{
winrt::hstring title = item.Title().Text();
p->SendMessageToOutputWnd(WM_APP, COutputWnd::OutputBuild, (LPARAM)title.c_str()); // print a string to an output window in the output pane.
}
}
There are two changes that I made from the source of the concurrency::create_task() being replaced:
- removed the
winrt::init_apartment(); and winrt::uninit_apartment(); since using them triggered an exception and removing them seems to make no difference
- moved the
Sleep(5000); to after the co_await since leaving it where it was caused the function to sleep for 5 seconds which meant the UI thread slept for 5 seconds
What I found with the debugger was that at the point that the function myTaskMain() was called, there was an immediate return from the function and the UI thread continued running while the coroutine executed in the background. The UI displayed promptly and then some five seconds later the additional actions, updating the Class View tree and the RSS feed list in the "Build" tab of the Output Window happened.
Note #1: One other thing I have run into with other testing is that the UI will freeze for a few seconds (menu is non-functional). This seems to be due to the Sleep(5000); indicating that the code after the co_await is being run on the main UI thread. This change in application behavior started after I began to explore using winrt::apartment_context ui_thread; to capture the main UI thread context in order to then use co_await ui_thread; to return my coroutine thread to the main UI thread context.
What may be happening is that client.RetrieveFeedAsync(uri) is immediately being satisfied with no delay, perhaps from a cache, so rather than pushing the task to another thread and then returning to the caller, the co_await is getting an immediate result back and the function myTaskMain() is able to immediately continue using the current thread which is the main UI thread?
I noticed that in Visual Studio 2017 the co_await used with client.RetrieveFeedAsync(uri) is colored green while the co_await used with co_await ui_thread; is blue. Doing a mouse hover over the green colored co_await I get a tool tip indicating this is a different version of co_await.
![screen shot of mouse hover over green co_await showing operator overload]()
Note #2: There is a C++/WinRT function to move to a background thread context, winrt::resume_background() which can be used with co_await. If I modify the above function myTaskMain() by replacing the line of code of Sleep(5000); after the call to client.RetrieveFeedAsync(uri) with the following two lines of code to push the thread context to a background thread, I do not see the freeze (the UI is responsive to menu selections) and the RSS feed text lines are displayed in the "Build" tab of the Output Window after some 15 seconds.
co_await winrt::resume_background(); // switch context to background thread
Sleep(15000);
Rolling an async task using concurrency::task<> that works with co_await
One thing I was curious about was being able to create my own async task that I could used with co_await similar to the async type functions of C++/WinRT. I spent some time searching about until I finally found this article, Concurrency and asynchronous operations with C++/WinRT, with a section called Asychronously return a non-Windows-Runtime type.
Here is a simple demo function that creates a concurrency::task<> with a lambda and returns the task which is then used with co_await. This particular lambda is returning an int so the function is defined as a task that returns an int, concurrency::task<int>
concurrency::task<int> mySleepTaskAsync()
{
return concurrency::create_task([]() {
Sleep(15000);
return 5;
});
}
The above function is then used with the co_await operator in a statement such as:
int jj = co_await mySleepTaskAsync();
which will cause the variable jj to have a value of 5 after a wait of 15 seconds.
The above is used in a function that returns a winrt::Windows::Foundation::IAsyncAction such as the function myTaskMain() above.
If you like you can also just directly use the lambda with the co_await as in:
int jj = co_await concurrency::create_task([]() {
Sleep(15000);
return 5;
});
Or you could have a normal function such as:
int mySleepTaskAsyncInt()
{
Sleep(15000);
return 5;
}
and then use it with a co_await using concurrency::task<> as in:
int jj = co_await concurrency::create_task(mySleepTaskAsyncInt);
Rolling an async task using std::async that works with co_await
While std::thread does not work with co_await, causing a compilation error, you can use std::async with co_await. The reason is the kind of return value that co_await operator requires and the difference in the return value of std::thread, a std::thread, and the return value of std::async, a std::future<>.
The co_await operator requires that the variable it is operating on is a std::future<>, has a get() method to retrieve a result from the thread, and is Awaitable.
#include <future>
int mySleepTaskAsyncInt()
{
Sleep(7000);
return 5;
}
winrt::Windows::Foundation::IAsyncAction myTaskMain(CMainFrame *p)
{
auto t1 = co_await std::async (std::launch::async, mySleepTaskAsyncInt);
// do something with the variable t1
}
Rolling an async task with std::packaged_task<> and std::future<> with co_await
As the co_await requires an Awaitable object, another way to create such an object is to create a task with std::packaged_task<> then start the task and use the get_future() method of the task to obtain a std::future<> which is then usable with co_await.
For instance we can have the following simple function that will create a task package, start the task executing, and then return a std::future<>. We can then use this function as the target for the co_await operator to implement a coroutine.
#include <future>
std::future<int> mySleepTaskStdFutureInt()
{
// create the task to prepare it for running.
std::packaged_task<int()> task([]() {
Sleep(7000);
return 455; // return an int value
});
// start the task running and return the future
return task(), task.get_future();
}
and then in our source code we would use this function similar to:
int jkjk = co_await mySleepTaskStdFutureInt();
The return statement is using the comma operator to introduce a sequence point so that we start the task running and then call the get_future() method on the running task. The result of the get_future() method, a std::future<int> is what is actually returned by the function.
The task that is created with std::packaged_task() must be started with a function like call using the variable. If you do not start the task then the std::future<> returned by the function will never have a variable and the co_await that is waiting for the Awaitable to complete and to provide a value will never fire. The result is that the source after your co_await will not be executed because the co_await will never be triggered.
Generator with co_yield and std::experimental::generator<type>
While investigating co_await I came across co_yield which is used to return a value as part of a generator of a set of values. With Visual Studio 2017 using co_yield requires that the header file experimental/generator be included. Here is a simple example of a generator that generates a series of integers.
#include <experimental/generator>
std::experimental::generator<int> makeSomeInts(int kCount)
{
for (int i = 0; i < kCount; i++) {
co_yield i;
}
}
And this function can be used with a ranged for as in:
for (int kkk : makeSomeInts(10)) {
// code that uses the variable kkk which contains
// an int from the generated range 0 up to be not including 10.
}
The above loop will be executed for each integer value of 0 through and including 9.
More complex message: updating ClassView pan
I also did an experiment with the ClassView tree control to provide a simple way of doing the most elementary actions: create an initial tree control and add to it.
In CClassView class in the file ClassView.h, I added the following data structs. By the way after I was done, I realized this was probably the wrong place to put this since the CFileView class uses the same tree structure so the same approach would work for both of these panes. Anyway, I added the following:
// ADD_ON: enumeration listing the various types of tree control icons which
// correspond to the position of a control in the tree.
// choose either classview_hc.bmp or classview.bmp for the bitmap strip that
// contains the 7 icons we are using for the images in our tree control.
// icons are standard size in height and width (15x15 pixels) in the order of:
// - main root icon
// - tree node icon which can be opened to show nodes beneath it
// - folder icon which is used to indicate a folder
// - method icon indicating a method of a class
// - locked method icon
// - member variable icon
// - locked member variable icon
enum IconList { MainRoot = 0, TreeNode = 1, FolderNode = 2, MethodNode = 3, MethodLockedNode = 4, MemberNode = 5, MemberLockedNode = 6 };
// ADD_ON: struct used to contain the necessary data for a node in the tree control.
struct ItemToInsert {
std::wstring label; // text to be displayed with the node.
int nImage; // zero based offset of the node's icon in the image, one of enum IconList above.
int nSelectedImage; // zero based offset of the node's icon in the image, one of enum IconList above.
};
I created a message handler, and added it to the message map in ClassView.cpp
ON_MESSAGE(WM_APP, OnAddItemsToPane)
and added the actual message handler itself along with a helper function that does the actual processing.
// ADD_ON: function for filling in the ClassView pane using an array of the
// struct ItemToInsert above. array is terminated by an entry with
// all zeros as in { _T(""), 0, 0 }
void CClassView::AddItemsToPane(CViewTree &xwndClassView, void *xrayp)
{
if (xrayp == 0) return;
// the images are icons that are laid out in a line of icons within a single bitmap image.
// see class method OnChangeVisualStyle() for when the bitmap image is loaded and then
// divided up into sections, 0 through 6, of the single bitmap image loaded.
// see classview.bmp and classview_hc.bmp in the ResourceFiles list.
HTREEITEM hRoot = xwndClassView.GetRootItem();
HTREEITEM hClass = 0;
ItemToInsert *xray = (ItemToInsert *)xrayp;
for (int i = 0; xray[i].label.size() != 0; i++) {
switch (xray[i].nImage) {
case MainRoot:
hRoot = xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage);
xwndClassView.SetItemState(hRoot, TVIS_BOLD, TVIS_BOLD);
xwndClassView.Expand(hRoot, TVE_EXPAND);
break;
case TreeNode:
hClass = xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage, hRoot);
break;
case FolderNode:
hClass = xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage, hRoot);
break;
case MethodNode:
case MethodLockedNode:
case MemberNode:
case MemberLockedNode:
xwndClassView.InsertItem(xray[i].label.c_str(), xray[i].nImage, xray[i].nSelectedImage, hClass);
break;
default:
break;
}
}
}
// ADD_ON: message handler for the WM_APP message containing an array of the
// struct ItemToInsert above. Uses method AddItemsToPane().
LRESULT CClassView::OnAddItemsToPane(WPARAM wParam, LPARAM lParam)
{
switch (wParam) {
case 1:
AddItemsToPane(m_wndClassView, (void *)lParam);
break;
}
return 0;
}
I then created some sample data for an initial tree and then an add on node.
// ADD_ON: this is the content to be put into the ClassView tree pane.
// this is a tree structure.
CClassView::ItemToInsert xray2[] = {
{ _T("CFakeMainProject"), CClassView::MainRoot, CClassView::MainRoot },
{ _T("CFakeAboutDlg"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAboutDlg()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeApp"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeApp()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("InitInstance()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("OnAppAbout()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeAppDoc"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAppDoc()"), CClassView::MethodLockedNode, CClassView::MethodLockedNode },
{ _T("~CFakeAppDoc()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("OnNewDocument()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeAppView"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAppView()"), CClassView::MethodLockedNode, CClassView::MethodLockedNode },
{ _T("~CFakeAppView()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("GetDocument()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("CFakeAppFrame"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CFakeAppFrame()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("~CFakeAppFrame()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T("m_wndMenuBar"), CClassView::MemberLockedNode, CClassView::MemberLockedNode },
{ _T("m_wndToolBar"), CClassView::MemberLockedNode, CClassView::MemberLockedNode },
{ _T("m_wndStatusBar"), CClassView::MemberLockedNode, CClassView::MemberLockedNode },
{ _T("Globals"), CClassView::FolderNode, CClassView::FolderNode },
{ _T("theFakeApp"), CClassView::MemberNode, CClassView::MemberNode },
{ _T(""), 0, 0 }
};
CClassView::ItemToInsert xray3[] = {
{ _T("CAdditionalDelay"), CClassView::TreeNode, CClassView::TreeNode },
{ _T("CAdditionalDelayMethod()"), CClassView::MethodNode, CClassView::MethodNode },
{ _T(""), 0, 0 }
};
I then exercises this message handler by spinning off two concurrency tasks in the CMainFrame::OnCreate() method which did a time delay and then updated the ClassView window tree contents.
concurrency::create_task([this]() { Sleep(5000); this->SendMessageToClassView(WM_APP, 1, (LPARAM)xray2); });
concurrency::create_task([this]() { Sleep(10000); this->SendMessageToClassView(WM_APP, 1, (LPARAM)xray3); });
std::thread(foo).join()will block the parent GUI. UseAfxBeginThreadif possible.SendMessagewaits for completion,PostMessagereturns immediately. – Kellykellyannresume_background). – RhadamanthusAfxBeginThreadshould be preferred. One can usestd::thread::join()in UI thread, when the UI thread already knows that the thread is about to end (e. g. when receiving a "finished" notification from the thread viaPostMessage()). Another way is to run your own message loop usingMsgWaitForMultipleObjectsEx(), passingstd::thread::native_handle()handle. – Holmesconcurrencynamespace and coroutines, was going to start experimenting. Seems to be several, converging technologies C++11, C++17, C++20, Microsoft specific. Are you suggestingconcurrencynamespace? – ImpreciseAfxBeginThreadis also always a heavy, OS thread which may not be appropriate, not really similar to thread pools of C++/WinRT.std::threadmay be similar toAfxBeginThreadin startup costs. Was looking atstd::asyncas well and am coming to conclusion that C++/WinRT does the "asynchronous task" thing better than standard C++. – ImpreciseDualApiPartitionAttribute. C++/WinRT as a header-only library can be dropped into just about any project. There is documentation in the MSDN on Concurrency and asynchronous operations with C++/WinRT, that showcases how to use coroutines. You'll have to use the /await compiler option. – RhadamanthusDualApiPartitionAttributeand I have added Note #3 and Note #4 with a link to a brief article about it. I assume any MFC source using C++/WinRT will need to be COM aware usingOleInitialize()? Or perhaps ` AfxOleInit()` with MFC? – Imprecisestd::thread::joinstops the message loop. Your solution about creating a different message loop is not trivial, and even less portable. Anyway, I think that's going off-topic. – KellykellyannCWinThreadderived object? It works so well with MFC. And you can post messages back and forth all day long between the thread object and your main thread. I use one that runs the whole time the app is alive to spell check and thesaurus several windows concurrently. It works great.. – TombouctouCWinThreadbefore. I was hoping to move into C++11/17 by using C++ standard collections and functionality as much as possible and MFC other than the window framework as little as possible. So the idea was to not useCWinThread,CString, etc. see this discussion though it is from 2009 #1348578 and I seem to remember a recommendation some time back in a Microsoft article to prefer STL to MFC in new code. – ImpreciseRoInitialize(). Thus far I found these two short blog posts from Sep 2012 about "Accessing WinRT from Desktop apps", blogs.microsoft.co.il/pavely/2012/09/13/… and blogs.microsoft.co.il/pavely/2012/09/24/… and there is this post that provides some details which may be too low level actually social.technet.microsoft.com/wiki/contents/articles/… – Imprecise