0

I currently have 3 very similar, but slightly different mfc applications, which would normally be opened at the same time as part of their workflow and usage in a Windows environment. I would like to keep them as 3 separate applications, but somehow group them together, under a single UI container to provide more clarity to the user.

I've so far considered using named pipes to send data from two of the applications to the third, the latter one being solely responsible for drawing the GUI (possibly having 3 different tabs at the highest GUI level, one for each application). I got this idea from SergeWautier's answer from this post. After looking into the possibility of doing this, there seems to be a lot of work involved in achieving this.

Is there any other (possibly simpler) way of achieving something similar?

Community
  • 1
  • 1
Claudiu
  • 155
  • 1
  • 3
  • 14
  • Do you always need to run all 3 at the same time, or does each solve problems without the need for the other two? – franji1 Mar 08 '17 at 18:52
  • @franji1 They all solve problems without the need for the other two. However, a certain type of user would most likely use all 3; My aim is to improve this type of user's workflow and unclutter their screen. – Claudiu Mar 09 '17 at 11:04
  • I was looking at the possibility of integrating the three into one app if they all needed each other all the time (e.g. MDI w/3 views or SDI with 2 other dialogs), but that is not the usage case, so forget that idea. – franji1 Mar 10 '17 at 14:02

1 Answers1

0

Old answer

I have in the mean time come across the TaskSpace tool, which is the closest thing to what I'm looking for. It's liteware and getting the full functionality (e.g. saving a particular tabbing configuration, which I am most interested in) requires purchasing a licence. What would be really cool would be to restrict the user from adding any other windows apart from the 3 applications and have better control over the titles of the tabs & top-level window. At this point, writing a similar tool to TaskSpace would be the ideal solution.

I've also been playing around with tidytabs. It's not exactly what I want, because it doesn't provide a 'wrapper GUI', but I thought it's worth mentioning here in case it helps someone else.

Update

I've found exactly what I was looking for in Window Tabifier, which is open source and I can modify to fit my needs in accordance with the CPOL Licence provided. Very nicely written code too.

Claudiu
  • 155
  • 1
  • 3
  • 14
  • 1
    What the Code Project publication is failing to mention is, that it doesn't work in general. See [Is it legal to have a cross-process parent/child or owner/owned window relationship?](https://blogs.msdn.microsoft.com/oldnewthing/20130412-00/?p=4683) for details. – IInspectable Apr 07 '17 at 10:11
  • @IInspectable Thank you for the link! That's an interesting read, but I'm still not sure about it 'not working in general'. It solves a real-world problem & it works very well for me. Maybe I'm not knowledgeable enough to understand the argument though... – Claudiu Apr 07 '17 at 14:19
  • 1
    Building a cross-thread window hierarchy implies calling [AttachThreadInput](https://msdn.microsoft.com/en-us/library/windows/desktop/ms681956.aspx) (which the system does behind your back), which leads to all sorts of intricacies. [AttachThreadInput is like taking two threads and pooling their money into a joint bank account, where both parties need to be present in order to withdraw any money](https://blogs.msdn.microsoft.com/oldnewthing/20130619-00/?p=4043), for example. – IInspectable Apr 07 '17 at 14:41
  • @IInspectable That makes a bit more sense now, but to keep the analogy, I'm not just asking random people for money... I know the people who will be making the transaction and I've introduced one to the other. I'm also keeping this scheme 'in-house' (I'm only tabifying my applications, nothing else). Maybe I'm still too ignorant to see that I'm in the wrong, but until I hit a brick wall and things go hay-wire, I'm going to go ahead with this despite my possible foolishness. Thanks a lot for the resources though! If I ever see the errors of my ways, I will leave a message here. – Claudiu Apr 10 '17 at 12:51
  • 1
    You are using MFC. That means you have given up control over your message loop. MFC makes no promises as to whether its message loop implementation can sustain a cross-thread window hierarchy, without causing a dead lock. – IInspectable Apr 10 '17 at 13:31
  • @IInspectable I now think I understand what you're talking about. I even managed to get the window to hang! Using the tabifier with an application's window already tabified, if you then attempt to close that window's tab while also closing the application (killing the process), but the application is programmed to spawn a modal dialog before window close (WN_CLOSE) to confirm closing and you choose not to close it, the window will just hang, the process still working, but the GUI completely frozen. Your comments have been very useful, thanks, IInspectable! – Claudiu Apr 14 '17 at 16:16