Hi Mr. Goldman,
My first name is also David. Earlier in this thread, I sent some
replies to clarify some stuff to do with dos, console, TUI, and windows
behaviour to the mailing list. My replies may have caused you confusion
and frustration so I will apologize for that. I don't believe it was
Mr. Macek's intention to frustrate you or leave you hanging at any
point. Please understand everyone has other priorities. I don't think
anyone wanted to make you feel the way you do about wasting your time.
Also understand, win32 is no longer supported directly my Microsoft
itself so why would you want to continue to support this api? Consider
all the security vulnerabilities mentioned in the past couple of years
and all. Why aren't you migrating to win64+ api's?
At the source of the issue: You were looking for examples to do console
stuff from win32 api with the intention of tweaking the curses TUI
library.
The mailing list nudged you to specifically the curses wcon_setcolor()
uses Win32 APISetConsoleTextAttribute(). The curses file that contains
wcon_setcolor() also contains other calls that use win32. I think that
answer was clear and concise.
If there is another question you are waiting for an answer on for
further clarification, by all means ask it again.
On 03/08/2016 06:56 PM, Daniel Goldman wrote:
> You continue to argue about a tangential issue. I've asked multiple
> times if you are a win32 api or curses programmer. You never answered.
> You apparently are not. If not, what makes you think you have special
> insights? And why do you continue to pursue tangential topics? My last
> post, I said we were in agreement, giving you an out to stop wasting
> time and space. But you won't let up. I'm sorry, you don't seem to have
> much common sense in dealing with people.
>
>>> Right, they agreed with me.
>>
>> They provided an example of how `wcon_setcolor` is implemented
> > using Win32 API calls, including `SetConsoleTextAttribute`.
> > Whether that's agreeing with you or not, I'd rather not guess.
>
> I agree it's best not to guess. I would never guess about something that
> I'm not knowledgeable about. In my previous post I explained about the
> api calls in the library file.
>
>>>> Anyway, try this. Run mintty and inside run `/usr/bin/mc | tee ~/foo`.
>>> > In mc, enter a directory, open a dialog or whatever. Kill the mc
>>>> process (for example using the Task manager). Close mintty and
>>> > open a new one. Run `cat ~/foo`. The last state of mc's TUI should
>>> > appear in the new mintty window.
>>>
>>> What did you expect? I think that makes my point perfectly. In the real
>>> world, we don't direct mc output through a pipe! I'm sure you know the
>>> difference, it's very basic. TUI Programs like mc are fundamentally
>>> different from command line programs like grep, both in how they are
>>> programmed and how they are used. Even given that you do not know how to
>>> program in curses, where the difference is obvious at the source code
>>> level, from a user point of view the difference is obvious.
>>
>> I'm not disputing that TUI and non-TUI programs are different.
>
> If that is the case, can you please stop wasting time arguing about
> mostly off-topic issues (that you don't seem to know much about)?
>
>> I wastrying to provide evidence in reply to """I stand by my
> > statement that "curses programs do not normally use
> > stdin, stdout, or stderr", but am ready to be corrected and learn.""".
>>
>> I thought this exercise would convince you that the program (the
> > curses part of it, to be precise) is not communicating with
>> the terminalwindow via any other channels than std{in,out}.
>
> I didn't need convincing. One would basically never use "stdin" or
> "stdout" in writing curses code. Words matter. Unfortunately, you have a
> loose way with words, eg "regular windows program".
>
>> I was hoping to demonstrate that by showing that `cat`,
>> not acurses program, can create the same terminal output
> > as a curses program.
>
> Well, now you've demonstrated it. Again, what did you expect? Again, in
> the real world, we don't direct mc output through a pipe.
>
>> Which part of the argument do you disagree with, if any?
>
> I already explained. Read the previous post (included above).
>
> --------------------
>
> My original question was a practical question concerning best ways to
> compile and run curses programs from within MSYS2. You were not helpful
> in answering that question, I don't blame you, how could you know?
> Someone else (Greg Jung) gave me quite helpful information, I appreciate
> that. The issue is still mostly not resolved, but there was at least a
> little progress.
>
> It is unfortunate that you've launched into a mostly theoretical
> discussion concerning win32 and curses programs. I think it's more
> helpful to MSYS2 users to have practical information and directions. I
> think this thread turned into a waste of time long ago (besides being
> mostly off-topic). Again, refer to my previous post where I suggested we
> are in agreement.
>
> Daniel
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> _______________________________________________
> Msys2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
