0

I posted this under another title, but this a more descriptive one. Here is a function found in an old library I'm using:

Friend Function GetResponse(ByVal MsgText As String, Optional ByVal DialogTitle As String = "Error Log", Optional ByVal MsgButtons As MessageBoxButtons = MessageBoxButtons.OK, Optional BoxIcon As MessageBoxIcon = MessageBoxIcon.Information) As DialogResult
    Return MessageBox.Show(MsgText, DialogTitle, MsgButtons, MessageBoxIcon.Question)
End Function

This was written in the WinForms era, but now I'm moving some code to WPF and newer. As a result, things like MessageBoxIcon and DialogResult don't exist, and the code will not compile.

I can return a bool instead of DialogResult, but things like MessageBoxIcon have different names and are located in different libraries under WPF. It would seem this would be a place to use IFDEF, but what would that trigger on? Is there a const that tells you your in WPF vs WinForms vs. whatever? Or is there some other way to make a single MsgBox that works in either?

I'm not looking to replace MsgBox with new code, I'm looking to have a single method that works in both WinForms and WPF because I have projects using both that call other code in this library so it has to be included.

Maury Markowitz
  • 9,082
  • 11
  • 46
  • 98
  • *Don't* post the same thing twice. Fix the other question. Multiple posts only create noise – Panagiotis Kanavos Oct 31 '17 at 14:45
  • Possible duplicate of [Is there a MessageBox equivalent in WPF?](https://stackoverflow.com/questions/3830228/is-there-a-messagebox-equivalent-in-wpf) – Panagiotis Kanavos Oct 31 '17 at 14:46
  • The appropriate class for WPF is System.Windows.MessageBox – Panagiotis Kanavos Oct 31 '17 at 14:47
  • The equivalent method is [public static MessageBoxResult Show( string messageBoxText, string caption, MessageBoxButton button, MessageBoxImage icon )](https://msdn.microsoft.com/en-us/library/ms598709.aspx) – Panagiotis Kanavos Oct 31 '17 at 14:49
  • @PanagiotisKanavos - I think you are missing the problem. I have this library filled with code and I import it into both WinForms and WPF. However, this single method causes WPF to choke. So how to I make a single function that will not choke one or the other? – Maury Markowitz Oct 31 '17 at 20:27

1 Answers1

1

If you aren't still actively maintaining this library for use with winforms code, or if the library itself isn't likely to change much in the future, translate it into WPF. You don't necessarily want to add a dependency on System.Windows.Forms.dll just to avoid writing a little extra code.

Otherwise, you might consider writing a WPF wrapper around it that translates WPF enums into winforms enums. But if the code you provide is a fair sample of what's in there, maintaining a wrapper might be as much work as maintaining a WPF version of the library itself.

You could use dependency injection: Rewrite the library to use some kind of IMessageBox interface. Each client of the library, winforms or WPF, would provide its own implementation of IMessageBox. This would be a pleasant and profitable programming exercise.

You can add a reference to the System.Windows.Forms assembly to a WPF project and use stuff from it. I just tested calling System.WIndows.Forms.MessageBox.Show() from WPF. Works fine.

System.Windows.Forms.MessageBox.Show("test", "caption", 
    System.Windows.Forms.MessageBoxButtons.OKCancel, 
    System.Windows.Forms.MessageBoxIcon.Error);

You could simply use the winforms enums in WPF, or you could write a wrapper that translates WPF enums into winforms enums.

  • [System.Windows.MessageBox](https://msdn.microsoft.com/en-us/library/ms602949.aspx) is already available for WPF – Panagiotis Kanavos Oct 31 '17 at 14:47
  • 1
    Then why propose something different? The answer should explain that `AbortRetryIgnore` is missing. Adding *another* dependency costs – Panagiotis Kanavos Oct 31 '17 at 14:56
  • @PanagiotisKanavos OP seems aware that WPF has a messagebox. Everything costs something. Sometimes we add dependencies to avoid writing extra code. – 15ee8f99-57ff-4f92-890c-b56153 Oct 31 '17 at 15:13
  • @PanagiotisKanavos - I still have dozens of WinForms apps I maintain that call this method. I would like to make a single new project that uses WPF. But there are many other functions in that lib I need, so one way or the other I have to import it. – Maury Markowitz Oct 31 '17 at 20:23
  • @EdPlunkett - "You can add a reference to the System.Windows.Forms assembly to a WPF" - is this valid? It strikes me as the Wrong Thing to Do, but if it's not a problem then maybe its the solution. I tried the enum route, which seems like the best way, but when I declared a Friend it complained I was overriding the originals, and when I declared it Private of course it wouldn't let me expose them. Am I missing a simple trick here? – Maury Markowitz Oct 31 '17 at 20:29
  • @MauryMarkowitz I don’t know what you mean by “the enum route”. If you want to use any winforms types in a WPF project, you’re stuck referencing the whole mess — but if you’re distributing a winforms-using library with your WPF app, you’re already distributing winforms assemblies anyhow. It’s ugly, but the alternative is “porting” the library to WPF — or the dependency injection thing, which is looking better and better compared to the alternatives. – 15ee8f99-57ff-4f92-890c-b56153 Oct 31 '17 at 20:50
  • @MauryMarkowitz By the “enum route”, you mean just translating WPF enum into winforms equivalents? For that you’d be referencing the winforms assembly, you can’t define your own enums and cast them. But as I said you’re already distributing winforms binaries in that case — in for a penny and all that. – 15ee8f99-57ff-4f92-890c-b56153 Oct 31 '17 at 22:52
  • @EdPlunkett - geez, it sounds like there really is no good, general, solution here. As to the "enum route", I thought I could make my own enums identical to the ones in WinForms, but then of course it doesn't work under winforms. All of this would work if there was something I could IFDEF on. – Maury Markowitz Nov 01 '17 at 16:11