GUI Interface

[Raided]

GUI Interface, run with MBINCompiler.exe in the same folder as MBINCompilerGUI.exe

[Bananasft]

First off I don't know if windows forms should really be the go-to here. WPF seems more appropriate.

Apart from that why are you launching MBINCompiler.exe as a process? You can just use it as a reference and use the classes it exposes publicly, just like the tests are doing it.

[Raided]

Does it really matter? I mean it's a really small utility mean't intentionally for people that can't use cmd. It gives user input without clogging the main prog with Readlines. Besides I don't know WPF.

[TangentFoxy]

Definitely should be using WPF instead. It's similar enough it shouldn't be too difficult to adapt to..

[emoose]

Agreed about WPF, should be simple to make a small UI with it (it's pretty much drag&drop just like WinForms)

Using the classes directly would be much better than calling on the exe too, since that would let the GUI be fully self-contained, and you won't have to handle stuff like the exe being missing because the user is an idiot, etc.

[hhrhhr]

1. make shortcut for MBINCompiler.exe on desktop
2. drag'n'drop any .MBIN on shortcut
3. profit...

for what other purposes is supposed to use GUI???

[Raided]

@hhrhhr That method means user's do not get any output. (Indications of what the program is doing or has done.) On a side note, you don't have to make a shortcut.

@emoose From what I am understanding being self-contained means the GUI is built with the compiler? That would mean if the compiler gets updated the GUI would also. This is what I wanted to avoid by making it look for the .exe

[hhrhhr]

@Raided, why Console.ReadLine() does not help the user to see the entire output of the program?

[Raided]

@hhrhhr Sure, however emoose did not want to use Readlines in the base program to not mess up automation and consoles not auto closing.

[hhrhhr]

ok, ok. but I still do not understand what kind of people can not use cmd? modmakers are required to at least be able to type on the keyboard.

[Raided]

@hhrhhr I'm too lazy to use cmd, it's too slow. I built a gui where you can drop files on and get the output. I don't understand how it is a difficult concept to grasp? It's fine if you guys don't want it, but for sure I'm going to be using it. Then when the compiler can compile .mbin's I'll update it for that as well.

[hhrhhr]

Unleash the power of the command line, Luke.

• convert.cmd:

@echo off
for %%i in (%*) do (
    echo convert %%i...
    MBINCompiler.exe "%%i"
    echo.
)
pause

• make shortcut for this .cmd
• drag'n'drop one or more .MBINs on this shortcut

so, it fast, you can "drop files and get output". moreover, simply adding ">> log.txt 2>&1" can be obtained full text log file and open it with any text editor. how much time you will need to implement a save logs in the GUI? or scanning sub-directories? in "slow cmd" this is done a couple of lines.

[emoose]

It's not that we don't want a GUI, it's just that this one seems to have some issues with it (still using WinForms, still using external exe..)

Though you were right about:

From what I am understanding being self-contained means the GUI is built with the compiler? That would mean if the compiler gets updated the GUI would also. This is what I wanted to avoid by making it look for the .exe

Maybe using an external exe would be for the better in this case, though that does leave a chance of outdated exes being passed around...

But anyway, I think the official MBINC GUI should have a few more features, take the UI that @Bananasft has been working on, which includes a display of the XML data and afaik can decompile/recompile on the fly, sorta acting as an MBIN editor instead of just an MBINC frontend, that'd be the best kind of GUI for this project IMO.

Anyway I'll close this for now, but don't let this discourage you from working on your own UI, if you can make one as described above we'd most likely be happy to accept it :)