As far as the localization scheme is concerned, I kind of expected that sed
and awk
is available in Windows too (as part of Cygwin or Mingw).
But if they are not a hard dependency, I would say the same script can be
coded
in Windows as a batch script. (And called from tecmakewin.mak - this is the
makefile
used in Windows, right?).
I looked at IupSetLanguagePack() function. It is a good functionality. It
might be
used here. However, it won't help much. I mean, the main selling points for
the
change was:
1. separate language strings from code
2. use very simple text files (easy for translation), without any
code/syntax suger
3. let the machines generate the code without the need for
manual maintenance
Using the LED file, would fulfill 1) and partly also 2).
But the files would have to be distributed and loaded at runtime, which is
not optimal.
When using ledc compiler, we have the same situation as in my suggested
solution,
i.e. there is a need to transform an input file to a output C source.

  I understand your points but I still don't think it is what we want for
IUP. The fact that we already have ledc/lua turns everything very easy for
our applications. But if you are talking about automatic translations then
clear text would make more sense. Although they are still something that
can be converted to LED or Lua, then used in IupSetLanguagePack. Internally
IUP won't have to change.

Thanks,
Scuri




2017-10-11 19:32 GMT-03:00 Antonio Scuri <antonio.sc...@gmail.com>:

> > The first commit is just the Czech localization in the current scheme
> (similar
> > to the Spanish one). It doesn't bring any structure changes. I guess it
> could be
> > committed right away (before the other change is decided).
>
>   I would like to keep internal localization to a minimum and to only
> languages that we can translate ourselves. This resumes to English,
> Portuguese and Spanish. Other languages should be contributed in external
> files.
>
> Thanks,
> Scuri
>
>
> 2017-10-11 19:26 GMT-03:00 Antonio Scuri <antonio.sc...@gmail.com>:
>
>>   Regarding iupObjectCheck and invalid memory access, this function was
>> designed to catch an Ihandle* being used after it was destroyed. Some times
>> the native system triggers a notification after the Ihandle* was
>> destroyed, so we created a method to safely detect that situation so we can
>> abort it. iupObjectCheck may read 1 byte of an invalid memory but this
>> is harmless.
>>
>> Best,
>> Scuri
>>
>>
>> 2017-09-25 22:36 GMT-03:00 Ranier VF <ranier_...@hotmail.com>:
>>
>>> Hi,
>>> This is another report by Dr.Memory about IupObjectCheck,
>>>
>>> Error #2: UNADDRESSABLE ACCESS of freed memory: reading
>>> 0x03120db0-0x03120db1 1 byte(s)
>>> # 0 iup.dll!iupObjectCheck                    +0x8      (0x10006a48
>>> <iup.dll+0x6a48>)
>>> # 1 iup.dll!iupdrvRegisterDragDropAttrib      +0x1486   (0x100658b7
>>> <iup.dll+0x658b7>)
>>> # 2 iup.dll!iupwinBaseMsgProc                 +0x75b    (0x1005206c
>>> <iup.dll+0x5206c>)
>>> # 3 iup.dll!iupdrvImageDestroy                +0x2b8e   (0x1005ff5f
>>> <iup.dll+0x5ff5f>)
>>> # 4 iup.dll!iupwinBaseMsgProc                 +0x607    (0x10051f18
>>> <iup.dll+0x51f18>)
>>> # 5 USER32.dll!GetDC                          +0x6c     (0x7e368734
>>> <USER32.dll+0x8734>)
>>> # 6 USER32.dll!GetDC                          +0x14e    (0x7e368816
>>> <USER32.dll+0x8816>)
>>> # 7 USER32.dll!GetParent                      +0x16b    (0x7e37927b
>>> <USER32.dll+0x1927b>)
>>> # 8 USER32.dll!SendMessageW                   +0x48     (0x7e3792e3
>>> <USER32.dll+0x192e3>)
>>> # 9 USER32.dll!CreateMDIWindowA               +0x1bc    (0x7e39ff7d
>>> <USER32.dll+0x3ff7d>)
>>> #10 USER32.dll!DeregisterShellHookWindow      +0x6311   (0x7e3965d2
>>> <USER32.dll+0x365d2>)
>>> #11 USER32.dll!IsDlgButtonChecked             +0x1099   (0x7e375e94
>>> <USER32.dll+0x15e94>)
>>> #12 USER32.dll!IsDlgButtonChecked             +0x436    (0x7e375231
>>> <USER32.dll+0x15231>)
>>> #13 USER32.dll!GetDC                          +0x6c     (0x7e368734
>>> <USER32.dll+0x8734>)
>>> #14 USER32.dll!GetDC                          +0x14e    (0x7e368816
>>> <USER32.dll+0x8816>)
>>> #15 USER32.dll!IsWindowUnicode                +0xa0     (0x7e37a013
>>> <USER32.dll+0x1a013>)
>>> #16 USER32.dll!CallWindowProcW                +0x1a     (0x7e37a039
>>> <USER32.dll+0x1a039>)
>>> #17 iup.dll!iupwinBaseMsgProc                 +0x63f    (0x10051f50
>>> <iup.dll+0x51f50>)
>>> #18 USER32.dll!GetDC                          +0x6c     (0x7e368734
>>> <USER32.dll+0x8734>)
>>> #19 USER32.dll!GetDC                          +0x14e    (0x7e368816
>>> <USER32.dll+0x8816>)
>>> Note: @0:00:42.922 in thread 3384
>>> Note: next higher malloc: 0x031210c0-0x03121110
>>> Note: prev lower malloc:  0x03120d70-0x03120d8c
>>> Note: 0x03120db0-0x03120db1 overlaps memory 0x03120db0-0x03120dfc that
>>> was freed here:
>>> Note: # 0 replace_free               [d:\drmemory_package\common\a
>>> lloc_replace.c:2706]
>>> Note: # 1 iup.dll!IupDestroy        +0x111    (0x10006e42
>>> <iup.dll+0x6e42>)
>>> Note: # 2 iup.dll!IupDestroy        +0x8a     (0x10006dbb
>>> <iup.dll+0x6dbb>)
>>> Note: # 3 iup.dll!IupDestroy        +0x8a     (0x10006dbb
>>> <iup.dll+0x6dbb>)
>>> Note: # 4 iup.dll!IupDestroy        +0x8a     (0x10006dbb
>>> <iup.dll+0x6dbb>)
>>> Note: # 5 iup.dll!IupDestroy        +0x8a     (0x10006dbb
>>> <iup.dll+0x6dbb>)
>>>
>>> Perhaps, they are related.
>>>
>>> Best regards,
>>>
>>> Ranier Vilela
>>>
>>> ________________________________________
>>> De: Ranier VF <ranier_...@hotmail.com>
>>> Enviado: terça-feira, 26 de setembro de 2017 00:46
>>> Para: IUP discussion list.
>>> Assunto: Re: [Iup-users] IUP contribution: Czech localization + improved
>>> localization scheme + bug fixes
>>>
>>> Hi Jiří Klimeš,
>>> I´m glad you fixed IupObjectCheck bug.
>>> As reported before in this list, by Dr.Memory:
>>>
>>> You can take a look in another report by Dr.Memory?
>>>
>>> Error #3: UNINITIALIZED READ: reading 0x0012fd50-0x0012fd5c 12 byte(s)
>>> within 0x0012fd44-0x0012fd60
>>> # 0 system call NtUserThunkedMenuInfo parameter #1
>>> # 1 USER32.dll!SetSystemMenu                                    +0x3d9
>>>   (0x7e38fdbd <USER32.dll+0x2fdbd>)
>>> # 2 iup.dll!IupClipboard                                        +0x8f3b
>>>  (0x10071bbc <iup.dll+0x71bbc>)
>>> # 3 iup.dll!IupMap                                              +0x96
>>>  (0x1000c9a7 <iup.dll+0xc9a7>)
>>> # 4 iup.dll!IupCopyClassAttributes
>>> +0x1eea   (0x1001324b <iup.dll+0x1324b>)
>>> # 5 iup.dll!iupClassObjectSetAttribute                          +0x23c
>>>   (0x100100bd <iup.dll+0x100bd>)
>>> # 6 iup.dll!IupGetAttributes                                    +0x605
>>>   (0x10001ce6 <iup.dll+0x1ce6>)
>>> # 7 iup.dll!IupMap                                              +0xc6
>>>  (0x1000c9d7 <iup.dll+0xc9d7>)
>>> # 8 ntdll.dll!RtlReleasePebLock                                 +0xe
>>>   (0x7c910440 <ntdll.dll+0x10440>)
>>> # 9 main
>>>  [c:\usr\src\sales\app.c:154]
>>> Note: @0:00:43.015 in thread 3384
>>>
>>> Suspicios function is IupClipboard.
>>>
>>> Best regards,
>>>
>>> Ranier Vilela
>>> ________________________________________
>>> De: Antonio Scuri <antonio.sc...@gmail.com>
>>> Enviado: sexta-feira, 22 de setembro de 2017 17:55
>>> Para: blue...@centrum.cz
>>> Cc: IUP discussion list.; iup
>>> Assunto: Re: [Iup-users] IUP contribution: Czech localization + improved
>>> localization scheme + bug fixes
>>>
>>>   Hi,
>>>
>>>   First of all thank you for your contribution.
>>>
>>>   About 1) and 3):
>>>
>>>   Large scale modifications in IUP code will be more effective if we
>>> work together. Your modifications are interesting but I can not use it.
>>> They add a dependency to Linux tools to the Makefile that directly affect
>>> the Windows build.
>>>
>>>   I have an alternative that is more IUP friendly. The
>>> IupSetLanguagePack function accepts a IupUser element that can contain the
>>> string translations. This can be stored in a LED, Lua or C files. And
>>> directly loaded by IUP, no need for external tools. But we didn't have an
>>> fully complete example. So I downloaded your CZECH lang file and converted
>>> to the LED format. Notice that LED and Lua can also be converted to C files
>>> to embed in the application code.
>>>
>>>   Attached the CZECH utf8 file in LED and C format. Please take a look.
>>>
>>>   About 2):
>>>
>>>   Unfortunately we used "box" when we mean "frame", but for coherence
>>> with the attribute names, we have to maintain the name "box" where we used.
>>> The Spanish translation was actually incorrect, when it used "cuadro". So
>>> there is no need for another definition for now.
>>>
>>>   About the bug-fixes, I committed all of them. Thanks.
>>>
>>>   Regarding the GIT, we are a very small team, so keeping a mirror is
>>> not in our plans. I know it is more popular, but for now we are going to
>>> keep just the SVN. But feel free to mirror it anywhere. If I recall right
>>> there is already some mirror around, can't remember where.
>>>
>>>   I tried the issue tracker in the past, but it was so much work for us
>>> with not much benefit that I give up. So our discussion tool is this email
>>> list. Or you can send email directly to me.
>>>
>>> Best Regards,
>>> Antonio Scuri
>>>
>>>
>>> 2017-09-20 13:16 GMT-03:00 <blue...@centrum.cz<mailto:blue...@centrum.cz
>>> >>:
>>>
>>> Hello Antonio,
>>>
>>>
>>>
>>> some time ago I came across IUP. I started to play with it a bit.
>>>
>>> I found the toolkit very nice, mainly due to its simplicity and plain C
>>> API. Also
>>>
>>> integrated Lua binding is a great feature.
>>>
>>>
>>>
>>> I decided to contibute to the project to make it even better. As a
>>> start, I have
>>>
>>> made Czech localization (my native language). And because I found the
>>> current
>>>
>>> localization framework not much flexible and scalable, I made an
>>> enhancement
>>>
>>> to it too.
>>>
>>>
>>>
>>> I placed the code to my github repo, which is forked from unofficial
>>> github clone
>>>
>>> (thanks to great svn2github service).
>>>
>>>
>>>
>>> https://github.com/blueowl04/iup-github/commits/localize-czech
>>>
>>>
>>>
>>> The localize-czech branch contains 3 commits:
>>>
>>> 1. Add support for CZECH language
>>>
>>> 2. Don't use IUP_BOX ambiguously, split it to IUP_MARK_BOX and IUP_BOX
>>>
>>> 3. Make localization easier and more flexible
>>>
>>>
>>>
>>> In bug-fixes branch, I also published a few bugfixes, including one crash
>>>
>>> I encountered.
>>>
>>>
>>>
>>> https://github.com/blueowl04/iup-github/commits/bug-fixes
>>>
>>>
>>>
>>> Notes:
>>>
>>> * Unfortunatelly, your sourceforge SVN repository doesn't have an issue
>>> tracker.
>>>
>>>   Please consider adding the tickets system, that would allow managing
>>> issues,
>>>
>>>   including patches, etc. And a discussion tool would be good too.
>>>
>>> * It would be nice if the project had an official github mirror. Many
>>> people use
>>>
>>>   git these days and it would certainly help to popularize the project.
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Jiří Klimeš
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Iup-users mailing list
>>> Iup-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Iup-users mailing list
>>> Iup-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>>
>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users

Reply via email to