Why the RedirectStandardOutput does not have the necessary ANSI codes? - redirectstandardoutput

Ok here's a simple Console Application I made to test the RedirectStandardOutput of the Process.StartInfo.
foreach (c In [Enum].GetValues(GetType(ConsoleColor))
{
Console.ForegroundColor = c
Console.WriteLine("Test")
}
And below is the application result.
So as we can see the colors show beautifully on the console.
However, when I read the StandardOutput.BaseStream there's no color information, no ANSI codes, no nothing.
How do I capture the color information on the redirected stream?

The short answer is that the streams as given to you by the .NET Console class are purely character-based and return only textual data.
To get the extended color info, it would be necessary to P/Invoke the Win32 API ReadConsoleOutput. This will return, among other things, an array of COLOR_INFO structs containing the color attributes for each character. You might want to look at the ReadConsoleOutput pinvoke.net page to get started.

Related

Ignore formatting in Slack App when reading messages

I'm building a Slack App which is only interested in actual user input in message, regardless if it's bold, italic, or a web link.
What would be the best way to remove all the formatting characters, such as _, *, etc, and leave actual text only?
The best solution is actually to ignore the text param entirely, as it is inherently lossy, and to instead parse what you want from the blocks param, which gives an exact representation of what the user saw in their slack client message field when they posted their message.
To demonstrate this, here's a simple example
what you type
WYS
text
blocks[0]["elements"]["elements"]
parsing text from blocks
[a][space][*][b][*]
​a b
a *b*
[{"type":"text","text":"a "},{"type":"text","text":"b","style":{"bold":true}}]
a b
[a][*][b][*][←][←][←][space]
a *b*
a *b*
[{"type":"text","text":"a *b*"}]
a *b*
Unfortunately for now, the Slack API does not give you the blocks param in command events, only message events. Hopefully they will fix this, but until then you may wish to use regular messages instead of slash commands.
If you are using node.js there is a module for this:
https://openbase.io/js/remove-markdown/documentation
Note that this is for markdown and not Slack's variant mrkdwn so it might not work.
Managed to get the unformatted message in python by looping through the array.
def semakitutu(message, say):
user = message['user']
# print(message)
hasira = message['blocks']
hasira2 = hasira[0]['elements'][0]['elements']
urefu = len(hasira2)
swali = ''
for x in range(urefu):
swali=swali+hasira2[x]['text']
print(swali)
say(f"Hello <#{user}>! I am running your request \n {swali}")```

gsdll.init_with_args parameters for Win32 display device

I intent to use gsdll32 to display postscript in a Win32 window (not ghostview).
I need help with the parameters needed by gsdll_init_with_args.
The function immediately returns error -0x12 or -0x100.
I tried several parameter combinations in various sequences:
-sDisplayFormat=16#030804
-dDisplayHandle="1234"
-dDisplayResolution=96
-sDEVICE=display
postscriptfile.ps
As a second question:
What should the parameters be if I want to pipe in the postscript data programmatically ?
Examples would be nice.
Seppe
The supplied source code for Windows uses gs_dll_init_with_args(). If you look in /ghostpdl/psi/dwmain.c, function new_main(int argc, char *argv) then at about line 328 you can see the call happening.
You can follow this through in a debugger to see what the arguments look like (they get sanitised before arriving here). Get it to work the way you want on the command line, then break here with those arguments and you can see what your own code should be providing.
To send the data buffer-by-buffer, we don't have an example. However, you start by calling gsapi_run_string_begin(), then repeatedly calling gsapi_run_string_continue() until you exhaust the data, then call gsapi_run_string_end(). Obviously you will have to check the return code to see if an error occurred.
Finally; please check the AGPL to be sure you can conform to the license restrictions.

Receiving SMS from SIM

I'm wondering, when I try to receive sms text message from a SIM using AT+CMGL, can a message contain OK<CR><LF>? if so how should I know where is the end of the message?
Thanks
This is a good question, and as you have identified if the information text contains a final result code you loose, because there is no way to know.
This is partially covered in V.250 which forbids the modem to introduce false final result codes if it breaks up lines:
Note that the DCE may insert intermediate characters in very long
information text responses, in order to avoid overrunning DTE receive
buffers. If intermediate characters are included, the DCE shall
not include the character sequences "0 " (3/0, 0/13) or "OK"
(4/15, 4/11, 0/13), so that DTE can avoid false detection of the end
of these information text responses.
And also several command (+GMI, +GMM, +GMR, +GSN, +GOI and +GCAP) are explicitly forbidden to produce text that embed the OK final result code (but it does not mention anything about ERROR...).
Similarly for 27.007 it forbids some commands (+CGMI, +CGMM, +CGMR, +CGSN, +CEER and +CLAC) from containing OK (and again no mention of ERROR...).
27.005 does not specify anything regarding embedded final result codes, so to avoid the issue of embedded final result codes for AT+CMGL you need to read the message in PDU mode, there you have a guarantee that the information text will not contain OK, ERROR, etc.

How do format a date/time/number/currency in another locale?

How do i format something for another locale in Windows?
For example, in managed C# code, i would try to render a DateTime using en-US locale with:
String s = DateTime.Now.ToString(CultureInfo.CreateSpecificCulture("en-US"));
TextRenderer.DrawText(
e.Graphics, s, SystemFonts.IconTitleFont,
new Point(16, 16), SystemColors.ControlText);
And that works fine when my computer's locale is en-US:
It even works fine when my computer's locale is de-DE:
But it completely falls apart when my computer's locale is ps-AF:
Note: My sample code is in .NET, but can also be native.
Update: Attempting to set System.Threading.Thread.CurrentThread.CurrentCulture to en-US before calling DrawText:
var oldCulture = System.Threading.Thread.CurrentThread.CurrentCulture;
System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("en-US");
try
{
// String s = DateTime.Now.ToString(CultureInfo.CreateSpecificCulture("en-US"));
String s = DateTime.Now.ToString();
TextRenderer.DrawText(e.Graphics, s, SystemFonts.IconTitleFont, new Point(16, 16), SystemColors.ControlText);
}
finally
{
System.Threading.Thread.CurrentThread.CurrentCulture = oldCulture;
}
No help.
Nine, no help
Jack, no help
Eight, possible straight
King, possible flush
Ace, no help
Six, possible straight
Dave of love for the dealer
Ace bets.
Update Two:
From Michael Kaplan's blog entry:
Sometimes, GDI respects users (even if no one else does!)
GDI doesn't give a crap about formatting or really anything related to locales, with one single exception:
Digit Substitution
Any time you go to render text it will grab those digit substitution settings in the user locale (including the user override information) and use the info to decide how to display numbers.
And there is no way to override those settings at the level where GDI uses them.
i wonder how Chrome manages it. When i write digits here, in the stackoverflow question, Chrome renders them using latin digits:
0123456789
See:
What you are seeing is due to the digit substitution that occurs when your system's locale is ps-AF.
I believe that's OK -- Users of such a locale are used to seeing digits presented this way.
Normally the way this is done is slightly different, see here for example, but I don't actually think this should make any difference:
String s = DateTime.Now.ToString(new CultureInfo("en-US"));
An alternative is to set Thread.CurrentCulture to your desired locale.
I.e. do this:
Thread.CurrentCulture = new CultureInfo("en-US");
And you can then replace the first line of your code with this:
String s = DateTime.Now.ToString();
I am not quite sure, but I believe that this would solve the digit substitution issue as DrawText would now be based on the en-US culture, rather than ps-AF

How can I programmatically determine the current default codepage of Windows?

I have to convert the encoding of a string output of a VB6 application to a specific encoding.
The problem is, I don't know the encoding of the string, because of that:
According to the VB6 documentation when accessing certain API functions the internal Unicode strings are converted to ANSI strings using the default codepage of Windows.
Because of that, the encoding of the string output can be different on different systems, but I have to know it to perform the conversion.
How can I read the default codepage using the Win32 API or - if there's no other way - by reading the registry?
It could be even more succinct by using GetACP - the Win32 API call for returning the default code page! (Default code page is often called "ANSI")
int nCodePage = GetACP();
Also many API calls (such as MultiByteToWideChar) accept the constant value CP_ACP (zero) which always means "use the system code page". So you may not actually need to know the current code page, depending on what you want to do with it.
GetSystemDefaultLCID() gives you the system locale.
If the LCID is not enough and you truly need the codepage, use this code:
TCHAR szCodePage[10];
int cch= GetLocaleInfo(
GetSystemDefaultLCID(), // or any LCID you may be interested in
LOCALE_IDEFAULTANSICODEPAGE,
szCodePage,
countof(szCodePage));
nCodePage= cch>0 ? _ttoi(szCodePage) : 0;
That worked for me, thanks, but can be written more succinctly as:
UINT nCodePage = CP_ACP;
const int cch = ::GetLocaleInfo(LOCALE_SYSTEM_DEFAULT,
LOCALE_RETURN_NUMBER|LOCALE_IDEFAULTANSICODEPAGE,
(LPTSTR)&nCodePage, sizeof(nCodePage) / sizeof(_TCHAR) );

Resources