PS -- I thought it may or may not be relevant but I am using a monitor with
2560x1600 resolution.
On 11/28/2022 at 5:54 AM, Andrew Robinson wrote:
They are placed at the top manually. I also manually edited the config file
and set X=0, which causes the dialogs to appear 8 pixels from the left
They are placed at the top manually. I also manually edited the config file
and set X=0, which causes the dialogs to appear 8 pixels from the left edge of
the screen (or 2 pixels when the dialog has no min/max buttons).
On 11/28/2022 at 4:48 AM, Antonio Scuri wrote:
Are those dialogs maximize
Are those dialogs maximized or placed at the top manually?
Em dom., 27 de nov. de 2022 às 21:10, Andrew Robinson
escreveu:
> I measured the offset when all dialogs were set to X=0. The dialogs that
> have RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels
> whereas the don't
I measured the offset when all dialogs were set to X=0. The dialogs that have
RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels whereas
the don't have those parameters set have an offset of 8 pixels, so apparently
whatever is rendered in the titlebar of the dialog can affect its
Ola again,
When I place a dialog at the leftmost topmost corner of the Windows OS and
close the dialog, upon reinitialization the dialog will not appear where I
placed it but displaced by about 7 pixels. When I look at the config file that
was created by Iup, I am seeing:
[PolymerDB]
Height
PS -- I forgot to add: If you see anything you think I got wrong or isn't
clear, feel free to let me know so I can go back and correct any mistakes. I
won't take it personally because I love honest feedback.
On 2020-05-09 at 3:29 PM, Andrew Robinson wrote:
My final answer (updated):
The only
My final answer (updated):
The only program that seemed to work on my system was setlocale_utf8_vc15.exe,
but it while it didn't fail, it also didn't exactly pass because it returns a
string for a locale that doesn't exist in any current Microsoft documentation:
English_United States.utf8. I thi
Those are images from a console app, not a gui app. The output should be
to/from an IupText() box, and I'm not seeing an IupText() box in your screen
captures.
On 2020-05-08 at 10:56 AM, Antonio Scuri wrote:
I tested in Win10 and Win7, and in both the results are the same.
Em qui, 7 de mai de
What was listed for "Current locale" when it worked?
On 2020-05-07 at 3:12 PM, Antonio Scuri wrote:
Ok
My UCRTBASE version is 10.0.18362.387
The Visual Studio 2017 test I compiled and run using static and dynamic
libraries (ucrtbase.dll) worked, in the sense that after calling
setloca
Ok
My UCRTBASE version is 10.0.18362.387
The Visual Studio 2017 test I compiled and run using static and dynamic
libraries (ucrtbase.dll) worked, in the sense that after calling
*setlocale(LC_ALL,
".UTF8")* , the call to fopen using a UTF-8 filename with special
characters worked.
Best,
Sc
My final answer:
en-US en_US US .UTF8 Version Well Documented?
POCRT FailFailPass Fail8.0.2.0 N/A
MSVCRT FailFailPass Fail7.0.7601.17744 No
UCRTBASE PassFailFail Fail10.0.14393.2247 Yes
NOTE 1: Micros
Hi,
1. This function does not help?: GetLocaleInfoEx
2. Before windows 8, msvcrt.dll lacks __create_locale
3. EnumSystemLocalesEx (windows Vista/8), to get fully-qualified locale name.
4. https://docs.microsoft.com/en-us/windows/win32/intl/locale-identifiers
5. https://docs.microsoft.com/en-us/win
The files you sent are using ucrtbase.dll, which works no different than
msvcrt does. You do know that there are a great many other MS crt files, such
as msvcp100.dll and msvcp120.dll and so on? You want to try all those too? I'm
sure they won't work either.
I got kind of tired of playing this ga
The DLL is already on my computer. It's on every computer with Windows. If you
were going to send anything, maybe you could send the .lib file that is being
statically linked, except I already know what is in it: undocumented garbage.
I'm not going to reverse engineer their code, I'm just going to
All the programs I sent you are intentionally statically linked with the
run time library, except the mingw version. To avoid I have to send you the
respective DLL.
No, each Visual Studio now uses a different msvcrt.dll. I uploaded the
same samples built to use the run time in a DLL:
http://w
Hi,
VS2017 calls a static library while the rest of your programs make a dynamic
library call to msvcrt.dll. The code in the static library is much different
from the code for setlocale() in the msvcrt.dll.
Since I do not have VS2017 on my computer, can you change the default command
line param
But you used a compiler to test the functions, right? Which one? This is
important because we are testing the run time library that is different
depending on the compiler.
Here, calling setlocale(LC_ALL, NULL) did not work in any compiler...
Best,
Scuri
Em ter., 5 de mai. de 2020 às 10:34
I didn't test the compilers, I tested the functions. They don't always work as
advertised, and this may be one of those times for some strange reason that
only Microsoft can comprehend.
I used char* res = setlocale(LC_ALL, NULL);
On 2020-05-04 at 8:16 PM, Antonio Scuri wrote:
- Which compiler
- Which compiler you tested?
- What was exactly the code?
char* res = setlocale(LC_ALL, "");
char* res = setlocale(LC_ALL, ".UTF8");
char* res = setlocale(LC_ALL, ".0");
char* res = setlocale(LC_ALL, NULL);
char* res = setlocale(LC_ALL, ".NULL");
char* res = setlocale(LC_ALL, "NULL");
Best,
Scu
Preliminary Status:
The apps that work actually call setlocale() in msvcrt, but with MSVC2017 and
higher, the compiler substitutes calls to LocaleNameToLCID() and
LocaleLCIDToName(). The Microsoft website was totally useless and incorrect in
almost every regard for how this works, so with a littl
Vc15 is Visual Studio 2017
Em seg, 4 de mai de 2020 14:28, Andrew Robinson
escreveu:
> Just a quick question: you said, "I found out that it worked using
> setlocale only in Visual Studio 2017" but all you sent was VS2010-15 and
> not VS2017. I need setlocale_utf8_vc17.exe.
>
> On 2020-05-04 at
Thanks, got it! Will report back to you with my analysis when I finish my
investigation.
On 2020-05-04 at 9:23 AM, Antonio Scuri wrote:
You can download it here:
http://webserver2.tecgraf.puc-rio.br/~scuri/tmp/setlocale_utf8.zip
Best,
Scuri
Em seg., 4 de mai. de 2020 às 11:57, Antonio
Just a quick question: you said, "I found out that it worked using setlocale
only in Visual Studio 2017" but all you sent was VS2010-15 and not VS2017. I
need setlocale_utf8_vc17.exe.
On 2020-05-04 at 9:23 AM, Antonio Scuri wrote:
You can download it here:
http://webserver2.tecgraf.puc-rio.b
You can download it here:
http://webserver2.tecgraf.puc-rio.br/~scuri/tmp/setlocale_utf8.zip
Best,
Scuri
Em seg., 4 de mai. de 2020 às 11:57, Antonio Scuri
escreveu:
> Sure, I can't send it here. But I'll upload it and send you a link after
> lunch.
>
> Best,
> Scuri
>
> Em seg, 4 de mai d
Actually I did read what you wrote, the thing is, it isn't documented to work
like that, so I'm curious what Microsoft is up to. I did "forget" that you
said it only works with VS2017 but I was distracted by the fact that it was
never documented to work like that, so it's a puzzle I want to solve.
Sure, I can't send it here. But I'll upload it and send you a link after
lunch.
Best,
Scuri
Em seg, 4 de mai de 2020 11:54, Andrew Robinson
escreveu:
> Actually I did read what you wrote, the thing is, it isn't documented to
> work like that, so I'm curious what Microsoft is up to. I did "for
Okay, got it then. I like certain kinds of puzzles, and that is a good one.
Unfortunately I can't install VS2017 on any of my computers (security
reasons), so could you please send me the compiled binary file for that sample
code? Please?
Regards
Andrew
On 2020-05-04 at 6:46 AM, Antonio Scuri
You forgot the attachment
On 2020-05-03 at 7:40 PM, Antonio Scuri wrote:
BTW I tested the sample code I sent attached. It worked only in VS 2017, but
it worked. So there is hope.
But no, it is not a good solution.
Best,
Scuri
Em dom, 3 de mai de 2020 23:35, Antonio Scuri
escreveu
Nope. It is there, in the message from 3 days ago.
Best,
Scuri
Em seg, 4 de mai de 2020 10:44, Andrew Robinson
escreveu:
> You forgot the attachment
>
> On 2020-05-03 at 7:40 PM, Antonio Scuri wrote:
>
> BTW I tested the sample code I sent attached. It worked only in VS 2017,
> but it wor
BTW I tested the sample code I sent attached. It worked only in VS 2017,
but it worked. So there is hope.
But no, it is not a good solution.
Best,
Scuri
Em dom, 3 de mai de 2020 23:35, Antonio Scuri
escreveu:
> I think you didn't read what I wrote. Please take a look again...
>
> It
I think you didn't read what I wrote. Please take a look again...
It is supported starting in Visual Studio 2017.
Best,
Scuri
Em dom, 3 de mai de 2020 22:15, Andrew Robinson
escreveu:
> Now that I've tried it again, I vaguely remember what was wrong with
> setlocale(): ".UTF8" is not supp
Now that I've tried it again, I vaguely remember what was wrong with
setlocale(): ".UTF8" is not supported by Windows. The only languages supported
by Windows are listed here:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/language-strings?view=vs-2019.
Just so other people know, do not c
> could I recommend that you record this solution in your online help file
some place where it is easy to see and find, say like Product -->
International Considerations or something like that? I think it is that
important.
Yes. Good point.
> That is not a simple thing to request customers
Ola,
Fixing IupConfig() will help a lot. I was doing my own custom ini files but it
is far easier and the code is far more readable when using IupConfig().
So thanks for that.
Microsoft has both a #pragma and a function() for setlocale. I vaguely recall
using setlocale() and either I missed s
Hi,
I wrote a test that don't even use IUP, just to test fopen with UTF-8. It
is attached. I found out that it worked using setlocale only in Visual
Studio 2017. It seems to be a new feature. I decide to describe this in the
IUP documentation:
-
Hi Antonio,
The following code:
config = IupConfig();
IupSetAttribute(config, "APP_NAME", "xyz");
IupConfigLoad(config);
only seems to work if the current directory has no atypical (non-English)
characters in it, e.g. -- "E:\My\Files" vs "E:\My…\Files". I am using the
English version of Wi
36 matches
Mail list logo
