Hi Samuel Thibault,
I have now done what you asked me: output strings with wchar_t elements
(or L"..." literals) with the program compiled in unicode mode, and it
works as well.
Also I tried brlapi_enterTtyModeWithPath(NULL, 0, NULL); but this made no
difference. Still the focus goes to the virtual braille terminal when I
click on it, and my client doesn't receive the input.
But now I will be able to lend a real braille terminal to try things out.
Just to inform you what I want to do:
I want to write a program that produces output in the form of dot-patterns
that are displayed by the braille terminal. Preferably all 256 possible
dot-patterns, with any of the 8 dots set, should be possible to output. I
must either use a function to output the dot-patterns directly, if there
is one, or use 256 different characters of wchar_t, and let brltty use a
table to translate them to the right dot-patterns.
The Program should also receive dot-patterns entered on the braille
keyboard of the terminal, if there is one (alternatively, the user could
enter the dot-patterns on the PC-keyboard, but this is less-than-ideal).
Greets, Thomas Marquardt
>> > Now I tried to solve it by calling brlapi_acceptKeys()
>> > or brlapi_acceptAllKeys(), but it made no difference.
>>
>> Mmm, that's odd. I guess you made sure that your windows has the focus
>> when you are pressing the cells?
>
> Grembl, it looks like it's the brltty window box which steals the focus
> on click. I have no idea how to disable that. You can work around this
> by stealing braille control completely by replacing your enterTtyMode
> call with
>
> brlapi_enterTtyModeWithPath(NULL, 0, NULL);
>
> Of course, in production environment you should get back to
> a simple enterTtyMode call, to let brltty get back control when your
> application is not focused.
>> > I didn't include windows.h at all.
>> > It is a simple Win32 console application and does not need it.
>>
>> I'm realizing that brlapi.h actually includes windows.h itself at the
>> head, so it shouldn't matter.
>>
>> I'll have to check why unicode wasn't working.
>
> It works for me on cygwin, when using proper unicode strings, i.e.
>
> #define UNICODE 1 /* done by your IDE */
> #include <brlapi.h>
>
> int main(void) {
> /* Init stuf */
> ...
>
> brlapi_writeText(1, L"foobar");
>
> return 0;
> }
>
> I don't know how the microsoft compiler behaves regarding strings
> when it is in unicode mode. I'd have thought that since the windows
> headers automatically take the wide versions of functions, the microsoft
> compiler would automatically make strings wide, or tell the user to
> explicitly use wide strings, but from what you say the former doesn't
> seem to happen, and apparently you are not aware of having to do the
> latter.
>
> Just to make sure my understanding is correct, could you try to set back
> your IDE to unicode mode (so that UNICODE gets defined to 1), and use
> explicit strings like the code snippet above does?
>
> Samuel
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
