GRF WIZARD Just Released (2.0.2)

[FooBar]

This is done by most (Windows-based) command line tools, I don't understand wht the grfcodec doesn't implement this.

Is it? I've tried a handful in C:\Windows\System32 and most close themselves instantly. IMO it's fairly common for commandline programs to close themselves when not executed from the commandline. I'm not saying I'm a big fan of that behaviour, but it at least makes it understandable why it is the way it is.

[planetmaker]

terminating a programme when it's done doing its job is considered good behaviour and avoids needless spamming of windows to the desktop which all need separate closing. If you don't like it, choose to use a batch file or use proper parameters in your link to grfcodec or some of the other suggestions in http://superuser.com/questions/306167/h ... -execution

[Andrex]

...it's fairly common for commandline programs to close themselves when not executed from the commandline.

Being fairly common is not synonym of correctness. IMO, their developers don't give a darn about user experience, or haven't even heard about it. You can also find more suggestions command line tools usability here (read the very first suggestion).

Example app from a developer aware of user experience: (besweet encoder)

terminating a programme when it's done doing its job is considered good behaviour

We agree, but I haven't said anything about the program's behaviour when its done doing its job, please be so kind to re-read my post so I don't have to quote all around.

When the process fails because of incorrect parameters or user opening the program directly (without parameters), the program closes itself immediately in a matter of milliseconds. Can we assume that ALL users are aware of the difference between a command-line tool and a GUI app, and bother to read the documentation before using a program?

It's not a point of whether I like or dislike it, I was referring to usability and user experience in general terms of the program. Evidently, unusual concepts for lower-level software programmers.

[Rubidium]

As for the recommendations, GRFcodec implements at least 1, 2, 3, 5, 6, 7, 8, 9 and 10. I'm not completely sure about 4 though; it seems to be mostly implemented, but I'm not sure it is always.

Showing some GUI is extremely troublesome. There are at least 3 platforms where GRFcodec is used on, but there is no universal way of showing a GUI... which means at least 3 different GUIs need to be implemented. Then there is the problem that on at least one of the 3 platforms you were able to run GRFcodec without any GUI. When we add the GUI, GRFcodec wouldn't work on that platform anymore... of we need to create another build. Furtermore, showing such a blocking window means that any error triggers the need for the user to click something, which means any fault happening in an automated process blocks the application and the automated process. Since the major use of GRFcodec is in automated processes, it's going to be a nuisance when those processes fail as someone needs to manually intervene.

[Alberth]

It's not a point of whether I like or dislike it, I was referring to usability and user experience in general terms of the program. Evidently, unusual concepts for lower-level software programmers.

grfcodec uses the standard C/C++ way of handling command parameters, and exit. You can find it in any C/C++ book that deals with

Code: Select all

int main(int argc, char *argv[])

That interface is the only thing offered to the programmer of a C/C++ application by the C/C++ standard. Every standard C/C++ program in the world uses it. Standard C/C++ does not have a GUI, it only has input and output text streams. This is already for 25-30 years. Really very commonly known and stable stuff thus.

Microsoft, in its infinite wisdom, has however decided not to care about these programs. It's just one of the biggest programming languages used. Cannot be that useful, right?
So instead of providing a generic solution that can be used by all standard C/C++ programs running at the Windows operating system, they want every programmer to add a Windows-specific solution to this Windows-specific problem.

Clearly, marketing and money have won over common sense and working with available standards. Judging by the availability of C/C++, this has been going on for 25-30 years already. If you have major problems with how things work in Windows, maybe you should think again how you want to spend your money on an operating system.

[Eddi]

... but that's how microsoft has always worked in its ~30 year history. deviate ever so slightly from the standard so that all programmers have to adapt to the microsoft way, and abandon the other niche platforms.


anyway. once upon a time there was a setting to keep command line programs open after they finished. where that has gone in the various versions of windows i don't know. i haven't used windows that way for ages.