Re: [Iup-users] Request
Hi, Andrew wrote: >TIP: IUP is just a GUI framework and should not be involved in any UTF >>standards battles. IUP should just stick to the native encoding of the >underlying >OS (which is ANSI or UTF-16) and let the programmer be able to >seamlessly >call native Windows Unicode compliant functions without any >additional and >unnecessary overhead. I agreed. The simpler the better. Best regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] Make Tool: Premake
Hi, Only for reference. Premake is based in Lua and looks very promising. https://premake.github.io/ Best regards. Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] Small improvements to iup_controls
Hi, More small improvements to iup_controls. regards, Ranier Vilela iup_matrixex.patch Description: iup_matrixex.patch iupmat_aux.patch Description: iupmat_aux.patch iupmat_draw.patch Description: iupmat_draw.patch iupmat_mark.patch Description: iupmat_mark.patch iupmat_mem.patch Description: iupmat_mem.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] Small improvements to iup_win.
Hi, Small improvements to iup_win. regards, Ranier Vilela iupwin_button.patch Description: iupwin_button.patch iupwin_canvas.patch Description: iupwin_canvas.patch iupwin_str.patch Description: iupwin_str.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP core small improvements.
Hi, I have made a small improvements in some files of iup_core. Most is reduce scope for a declaration vars. But iup_names.c have a better improvement. regards, Ranier Vilela iup_image.patch Description: iup_image.patch iup_layoutdlg.patch Description: iup_layoutdlg.patch iup_list.patch Description: iup_list.patch iup_classinfo.patch Description: iup_classinfo.patch iup_colohsi.patch Description: iup_colohsi.patch iup_names.patch Description: iup_names.patch iup_str.patch Description: iup_str.patch iup_table.patch Description: iup_table.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP TRUNK msvc 2010, link errors
Hi Scuri, I am compiling iup trunk with msvc 2010, and are reporting the error below, could you help? ll10/draw.obj ../obj/dll10/fill.obj ../obj/dll10/font.obj ../obj/dll10/image.obj ../obj/dll10/init.obj ../obj/dll10/memstream.obj ../obj/dll10/misc.obj ../obj/d ll10/path.obj ../obj/dll10/string.obj ../obj/dll10/strokestyle.obj ../obj/dll10/ iupwindows_main.obj ../obj/dll10/iupwindows_help.obj ../obj/dll10/iupwindows_inf o.obj ../obj/dll10/iup.res iup.def : error LNK2001: unresolved external symbol IupPostMessage iup.def : error LNK2001: unresolved external symbol IupVersionShow iup.def : error LNK2001: unresolved external symbol iupArrayReleaseData iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientOffset iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientOffset Attrib iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientSizeAt iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientSizeAt trib iup.def : error LNK2001: unresolved external symbol iupClassObjectHasDlgPopup iup.def : error LNK2001: unresolved external symbol iupdrvGetPreferencePath ../lib/dll10/iup.lib : fatal error LNK1120: 9 unresolved externals ../tecmakewin.mak:1605: recipe for target '../lib/dll10/iup.dll' failed win-make[1]: *** [../lib/dll10/iup.dll] Error 1120 makefile:12: recipe for target 'iup' failed win-make: *** [iup] Error 2 regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP TRUNK msvc 2010, link errors
Hi, After clean all. The msvc claims this: ll10/iupwin_val.obj ../obj/dll10/iupwin_touch.obj ../obj/dll10/iupwin_tabs.obj . ./obj/dll10/iupwin_menu.obj ../obj/dll10/iupwin_list.obj ../obj/dll10/iupwin_tre e.obj ../obj/dll10/iupwin_calendar.obj ../obj/dll10/iupwin_datepick.obj ../obj/d ll10/iupwin_draw_wdl.obj ../obj/dll10/iupwin_draw_gdi.obj ../obj/dll10/iupwin_im age_wdl.obj ../obj/dll10/backend-d2d.obj ../obj/dll10/backend-dwrite.obj ../obj/ dll10/backend-gdix.obj ../obj/dll10/backend-wic.obj ../obj/dll10/bitblt.obj ../o bj/dll10/brush.obj ../obj/dll10/cachedimage.obj ../obj/dll10/canvas.obj ../obj/d ll10/draw.obj ../obj/dll10/fill.obj ../obj/dll10/font.obj ../obj/dll10/image.obj ../obj/dll10/init.obj ../obj/dll10/memstream.obj ../obj/dll10/misc.obj ../obj/d ll10/path.obj ../obj/dll10/string.obj ../obj/dll10/strokestyle.obj ../obj/dll10/ iupwindows_main.obj ../obj/dll10/iupwindows_help.obj ../obj/dll10/iupwindows_inf o.obj ../obj/dll10/iup.res iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientOffset iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientSizeAt ../lib/dll10/iup.lib : fatal error LNK1120: 2 unresolved externals ../tecmakewin.mak:1605: recipe for target '../lib/dll10/iup.dll' failed win-make[2]: *** [../lib/dll10/iup.dll] Error 1120 makefile:12: recipe for target 'iup' failed win-make[1]: *** [iup] Error 2 makefile:9: recipe for target 'iup' failed win-make: *** [iup] Error 2 regards, Ranier Vilela De: Ranier Vilela Enviado: quarta-feira, 15 de janeiro de 2020 10:45 Para: IUP discussion list. Assunto: [Iup-users] IUP TRUNK msvc 2010, link errors Hi Scuri, I am compiling iup trunk with msvc 2010, and are reporting the error below, could you help? ll10/draw.obj ../obj/dll10/fill.obj ../obj/dll10/font.obj ../obj/dll10/image.obj ../obj/dll10/init.obj ../obj/dll10/memstream.obj ../obj/dll10/misc.obj ../obj/d ll10/path.obj ../obj/dll10/string.obj ../obj/dll10/strokestyle.obj ../obj/dll10/ iupwindows_main.obj ../obj/dll10/iupwindows_help.obj ../obj/dll10/iupwindows_inf o.obj ../obj/dll10/iup.res iup.def : error LNK2001: unresolved external symbol IupPostMessage iup.def : error LNK2001: unresolved external symbol IupVersionShow iup.def : error LNK2001: unresolved external symbol iupArrayReleaseData iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientOffset iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientOffset Attrib iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientSizeAt iup.def : error LNK2001: unresolved external symbol iupBaseCanvasGetClientSizeAt trib iup.def : error LNK2001: unresolved external symbol iupClassObjectHasDlgPopup iup.def : error LNK2001: unresolved external symbol iupdrvGetPreferencePath ../lib/dll10/iup.lib : fatal error LNK1120: 9 unresolved externals ../tecmakewin.mak:1605: recipe for target '../lib/dll10/iup.dll' failed win-make[1]: *** [../lib/dll10/iup.dll] Error 1120 makefile:12: recipe for target 'iup' failed win-make: *** [iup] Error 2 regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-TRUNK dereference null return (src\iup_layoutdlg.c)
Hi, IupGetCallback function can return NULL, therefore it is necessary to check the return. best regards, Ranier Vilela iup_layoutdlg.patch Description: iup_layoutdlg.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-TRUNK dereference after null check (src\iup_export.c)
Hi, The var file is not properly protected, when call fprintf, and can be NULL. "passing null pointer file to fprintf" message from static tool analyser. best regards, Ranier Vilela iup_export.patch Description: iup_export.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-TRUNK Use After Free (win\iupwin_image.c 887 line)
Hi, win\iupwin_image.c (line 887) handle is freed at line 872, and is passed to function cb if has IMAGEDESTROY_CB. function cb they have no way of knowing that the pointer is invalid! Wouldn't it be better to call cb first, and then release the pointer? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP-TRUNK dereference null return (src\iup_layoutdlg.c)
Hi Scuri, I did not understand your answer, for me still with error. Do you mean that IupGetCallback (tree, "SELECTION_CB"); always return different than NULL in that context? regards, Ranier Vilela De: Antonio Scuri Enviado: quarta-feira, 15 de janeiro de 2020 13:18 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP-TRUNK dereference null return (src\iup_layoutdlg.c) Hi, It is true, but not in that context. There SELECTION_CB must be defined. Best, Scuri Em qua., 15 de jan. de 2020 às 09:39, Ranier Vilela mailto:ranier_...@hotmail.com>> escreveu: Hi, IupGetCallback function can return NULL, therefore it is necessary to check the return. best regards, Ranier Vilela___ Iup-users mailing list Iup-users@lists.sourceforge.net<mailto:Iup-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-TRUNK src\iup_dialog.c (745 line) dead code
Hi, src\iup_dialog.c iDialogCustomFrameButton_CB function. The logic in this function has problems. At line 678 the var "pressed" is tested, after this has: 1. at line 725 the var pressed is always true 2. at line 744 the var !pressed is always false 3, at line 745 dead code best regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP-r5619 warnings update
Hi, Some considerations about your report. With regard to gtk, it would be better for the project to support only the latest versions of the library, but according to Scuri, support for the old versions will continue, which makes it difficult to correct and use the updated functions. Several errors are related to third-party libraries, and in the case of IUP, some are out of date, it would be better to correct them first. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-3.28 src\iup_tree.c (Assigned a value that is never used)
Hi, src\iup_tree.c (line 661) Something is wrong with the iupTreeDragDropCopyCache function, should the id_src variable be a pointer? Because the attribution she receives is without effect. /* compensate because we add space for new nodes */ if (id_src > id_dst) id_src += count; // <== assigned a value that is never used. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.28 (iup_controls) useless assignment
Hi, Fix useless assigment in iup_cells.c regards, Ranier Vilela iup_controls.patch Description: iup_controls.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.28 some minor fixes in iup_core.
Hi, Attached patch to fix some minor fixes in iup_core. regards, Ranier Vilela iup_core.patch Description: iup_core.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Small improvements to iup_controls
Thank you Scuri. regards, Ranier Vilela De: Antonio Scuri Enviado: quinta-feira, 5 de março de 2020 16:49 Para: IUP discussion list. Assunto: Re: [Iup-users] Small improvements to iup_controls Applied, but had to fix a problem in one of the patches. Best, Scuri Em seg., 17 de fev. de 2020 às 20:19, Ranier Vilela mailto:ranier_...@hotmail.com>> escreveu: Hi, More small improvements to iup_controls. regards, Ranier Vilela___ Iup-users mailing list Iup-users@lists.sourceforge.net<mailto:Iup-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Patch to simplify IM's (r757) src/process/im_analyze.cpp
De: sur-behoffski Enviado: domingo, 26 de abril de 2020 00:39 Para: IUP discussion list. Assunto: [Iup-users] Patch to simplify IM's (r757) src/process/im_analyze.cpp G'day, I've been steering clear of IM, partially as much of its code is from third-party libraries, and partially because activity on the project SVN tree was so low. However, I notice that there were three SVN commits in the past few day, so, I've started looking at non-third-party code as a candidate for change. I'm trying to reduce GCC's warnings, without altering the code semantics in any way. I've found that there are a number of cases of the warning "-Wmisleading-indent", relating to the code: if (cm20) free(cm20); if (cm02) free(cm02); if (cm11) free(cm11); Looking at the documentation for free(3), it states that NULL (0) is explicitly allowed as a parameter, and the call will be a no-op. The GNU documentation states that this has been formalised at least in C89, as well as all C and C++ standards since: 30 years ago. I know that during the '80s, there were some C compilers that generated code which crashed if free(NULL) was called, but I believe that in the modern era, this concern is no longer valid. Similarly, I believe that the compiler toolchains handle the NULL case without heavily penalising the caller (perhaps by defining "free" as a macro internally, and doing the NULL check in the macro expansion before attempting a call). Therefore, the above code could be rewritten as: free(cm20); free(cm02); free(cm11); +1 I've tried without success, say what on that list. Which is a waste to test against NULL before calling free. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] CMake with msvc 2019 (32 bits)
De: Antonio Scuri Enviado: sexta-feira, 1 de maio de 2020 22:35 Para: IUP discussion list. Assunto: Re: [Iup-users] CMake with msvc 2019 (32 bits) > Thanks for the report. We are working in a full CMake support for Windows. > Those files were a contribution >originally for the additional drivers, I > think they were tested in MacOS and Android only. You are welcom.e > This should be released after the next version. We still have a long work > ahead. Thanks. Will need, a version with Release|Win32, please. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] CMake with msvc 2019 (32 bits)
Hi, First try with Cmake (latest) msvc 2019 (32 bits) windows 10 (64 bits) report from Cmake: C:\dll\iup\iup>cmake -G "Visual Studio 16 2019" CMake Warning: No source or binary directory provided. Both will be assumed to be the same as the current working directory, but note that this warning will become a fatal error in future CMake releases. -- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363. CMake Error at CMakeLists.txt:54 (PROJECT): Failed to run MSBuild command: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe to get the value of VCTargetsPath: Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Framework Copyright (C) Microsoft Corporation. All rights reserved. Build started 01/05/2020 19:25:29. Project "C:\dll\iup\iup\CMakeFiles\3.16.19112601-MSVC_2\VCTargetsPath.vcxproj" on node 1 (default targets). C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(387,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32. [C:\dll\iup\iup\CMakeFiles\3.16.19112601-MSVC_2\VCTargetsPath.vcxproj] Done Building Project "C:\dll\iup\iup\CMakeFiles\3.16.19112601-MSVC_2\VCTargetsPath.vcxproj" (default targets) -- FAILED. Build FAILED. "C:\dll\iup\iup\CMakeFiles\3.16.19112601-MSVC_2\VCTargetsPath.vcxproj" (default target) (1) -> (PrepareForBuild target) -> C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(387,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32. [C:\dll\iup\iup\CMakeFiles\3.16.19112601-MSVC_2\VCTargetsPath.vcxproj] 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.14 Exit code: 1 -- Configuring incomplete, errors occurred! regards, Ranier Vilela See also "C:/dll/iup/iup/CMakeFiles/CMakeOutput.log". ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
As already mentioned, most of the report refers to the third-party library, where they do not have access. Could you forward this report to the maintainers of these libraries? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
De: Antonio Scuri
Enviado: domingo, 17 de maio de 2020 17:23
Para: IUP discussion list.
Assunto: Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow
free(NULL); " patch...
> For me those "if"s are there also to remind me that those pointers where not
> allocated. For me one call to >malloc/calloc must match one call to free.
> Maybe I'm old, but I'll stick with that for now.
Certainly "call to malloc/calloc must match one call to free" is that is
correct, even if, two free for the same malloc would be double free.
The point is that IF it protects you from double free, only if the pointer is
marked as NULL, after the free as:
if (ptr) {
free(ptr);
ptr = NULL;
}
This is certainly defensive programming and protects the user, but it hides the
fact that they have a double free bug in the program.
At runtime, it makes no difference, calling free with NULL, as long as the
pointer has not been released before.
ptr = NULL;
free(ptr);
The big question is how to catch the double free that may exist.
Because this not to protect agaist double free.
if (ptr) {
free(ptr);
}
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
De: Antonio Scuri
Enviado: domingo, 17 de maio de 2020 17:23
Para: IUP discussion list.
Assunto: Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow
free(NULL); " patch...
> For me those "if"s are there also to remind me that those pointers where not
> allocated. For me one call to >malloc/calloc must match one call to free.
> Maybe I'm old, but I'll stick with that for now.
Certainly "call to malloc/calloc must match one call to free" is that is
correct, even if, two free for the same malloc would be double free.
The point is that IF it protects you from double free, only if the pointer is
marked as NULL, after the free as:
if (ptr) {
free(ptr);
ptr = NULL;
}
This is certainly defensive programming and protects the user, but it hides the
fact that they have a double free bug in the program.
At runtime, it makes no difference, calling free with NULL, as long as the
pointer has not been released before.
ptr = NULL;
free(ptr);
The big question is how to catch the double free that may exist.
Because this not to protect agaist double free.
if (ptr) {
free(ptr);
}
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow free(NULL); " patch...
De: Pete Lomax via Iup-users
Enviado: segunda-feira, 18 de maio de 2020 02:34
Para: IUP discussion list.
Cc: Pete Lomax
Assunto: Re: [Iup-users] Repeat of IM's "process/im_analyze.cpp allow
free(NULL); " patch...
On Sunday, 17 May 2020, 23:05:05 BST, Ranier Vilela
wrote:
The big question is how to catch the double free that may exist.
Because this not to protect against double free.
if (ptr) {
free(ptr);
}
>One tactic I have just recently started adopting, entirely independent of this
>and in fact in a completely different l>anguage is:
>ptr = ffree(ptr)
>where ffree() always returns null.
FFree comes in the case of defensive programming and depending on what is
inside it, it remains a waste.
Probably ffree is written something like this:
void * ffree (void * ptr) {
if (ptr) {
free (ptr)
}
return NULL;
}
I am using only free, without any ifs, and using tools to detect memory
problems, such as DrMemory on Windows.
If a double free occurs, it will certainly be detected either by me or by the
user.
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupConfig
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/windows/win32/intl/locale-names It seems to me that the problem is related to correctly naming the locale.. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29
De: Antonio Scuri Enviado: terça-feira, 19 de maio de 2020 02:43 Para: IUP discussion list. Assunto: [Iup-users] IUP 3.29 Hi All, We just released IUP version 3.29 Thank you Scuri, great new. regards, Ranier VIlela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupText APPEND Question
Hi,
Some functions in IUP only work after mapping.
IupSetAttribute(logText, "APPEND","YES\n");
IupSetAttribute(logText, "APPEND","NO\n");
"APPEND", I believe that is the case.
IupShowXY, IupShow, execute the map.
best regards,
Ranier Vilela
De: Moore, Tysen
Enviado: terça-feira, 24 de março de 2020 16:15
Para: iup-users@lists.sourceforge.net
Assunto: [Iup-users] IupText APPEND Question
I am new to the IUP project and so far so good. I have an issue trying to
append text to the IupText. I have looked at the examples and it seems very
straight forward. It seems that all I need is:
IupSetAttribute(logText, "APPEND","Something\n");
However, this is not working for me. I wasn't sure if there something else I
was missing. My basic code is: (taken from the
IupSubmenu)
Ihandle *dlg;
Ihandle *logText;
/* Initializes IUP */
IupOpen( , );
/* Creates a multiline */
logText = IupText (NULL);
/* Sets value of the text and turns on expand */
IupSetAttribute(logText, "EXPAND","YES");
IupSetAttribute(logText, "MULTILINE", "YES");
IupSetAttribute(logText, "APPEND","YES\n");
IupSetAttribute(logText, "APPEND","NO\n");
/* Creates dialog with a text */
dlg = IupDialog (logText);
/* Sets title and size of the dialog and associates a menu to it */
IupSetAttributes (dlg, "TITLE=\"IupSubmenu Example\", SIZE =
QUARTERxEIGHTH");
/* Shows dialog in the center of the screen */
IupShowXY (dlg, IUP_CENTER, IUP_CENTER);
IupSetFocus(logText);
IupMainLoop();
IupClose();
I expected to see the text:
YES
NO
Instead I have an empty IupText. I then added a timer using: (from a different
user list example)
int cb_timer(Ihandle *self)
{
IupSetAttribute(logText, "APPEND", "SOMETHING\n");
return IUP_DEFAULT;
}
Ihandle *timer;
timer = IupTimer();
IupSetInt(timer, "TIME", 1000);
IupSetCallback(timer, "ACTION_CB", (Icallback)cb_timer);
IupSetAttribute(timer, "RUN", "YES");
This code works as expected; every second it appends "SOMETHING" to the IupText.
Is there a call that needs to be made after the APPEND? From the examples I've
seen it seems this is not the case, unless there is something behind the scenes
that is causing this text to be written.
Any advice would be much appreciated, thanks in advance.
Tysen
I am using Ubuntu 18.04 building for GTK. (in case this info helps)
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Inline editing items in IupList
De: Cezary Drożak Enviado: segunda-feira, 14 de setembro de 2020 20:22 Para: iup-users@lists.sourceforge.net Assunto: [Iup-users] Inline editing items in IupList >I am considering switching from Qt to IUP and one thing I cannot find in IUP >is the possibility to edit items in IUP >inline like on this screenshot: >https://doc-snapshots.qt.io/4.8/images/stringlistmodel.png. >Is it possible to do it in IUP? It isn't a top priority, as I can always use a >pop up, but an inline editor would look >better >in my opinion. You tried? IupList with DROPDOWN=NO EDITBOX=YES regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP iupDlgListDestroyAll refactored
Hi Scuri,
Is there a special condition, so that the function below is not written like
this?
usr\iup_dlglist.c:
void iupDlgListDestroyAll(void)
{
Idiallst *list;
for (list = idlglist; list; list = list->next)
{
if (iupObjectCheck(list->ih))
{
IupDestroy(list->ih); /* this will also destroy the list */
list->ih = NULL;
}
}
}
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] [PATCH] Fix assorted readability names
Hi, Checking the IUP base code, there are several differences between the declarations and the implementation of the code. Most harmless, however, for reasons of readability, would it be better to correct? regards, Ranier Vilela assorted_readability_names.path Description: assorted_readability_names.path ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP assorted issues
Hi Scuri, Attached, new patch, with numerous suggestions for various corrections. Please review the patch, any questions, I am available. I will try to summarize some of the problems encountered, but as there are many, it may be that some of them have passed. 1. \ src \ iup_colorbrowser.c (184) diff1 <1 and diff2 <1 always false There must be a problem with the logic of this function, since the test will always be false, so I modified the test to an else if, maybe this is the expected behavior initially. 2. \ src \ iup_flatbutton.c (246, 268) Here again some logic error, because the assigned variable, will never be used (selected). 3. \ src \ iup_flattoggle.c (363, 368, 378, 397) Here again some logic error, because the assigned variable, will never be used (selected). 4. \ src \ iup_maskmatch.c (504) The pos variable, shadows another variable of the same name. 5. \ src \ iup_flattree.c (3432) Repeated if test, either it is redundant or it should be another test. 6. \ src \ iup_flattree.c (3570) I believe that the else should be 0 and not 1. 7. \ src \ gtk \ iupgtk_str.c (78) The test of the charset variable will always be true, so I redid the logic of the functions, simplifying it significantly, note that if: if (! charset || iupStrIsAscii (str)) if! charser is tested first, it doesn't need to be tested anymore. 8. \ src \ gtk \ iupgtk_list.c (646) ! value will always be false here, it can be safely removed. 9. \ src \ mot \ iupmot_font.c (254) I believe there is a bug here, but I don't know the correct solution, modfont is assigned but never used, I believe the function should be carefully reviewed. 10. \ src \ mot \ iupmot_canvas.c (73) I renamed the cb variable to cb_action, to not shade cb variable. 11. \ src \ mot \ iupmot_filedlg.c (90) There must be a bug here, because apparently ret_code never changes, so the rest of the function doesn't seem to work properly. 12. \ src \ mot \ iupmot_dialog.c (349) There must be a bug here, it should be: atoms [0] = state1; atoms [1] = state2; 13. \ src \ mot \ iupmot_tabs.c (300) Again shaded variable, reformulated to avoid. 14. \ src \ mot \ iupmot_text.c (684) The function deserves a careful review, because the value parameter is being shaded by another local variable, renamed to avoid it, but I don't know if it's the expected behavior. regards, Ranier Vilela assorted_issues.patch Description: assorted_issues.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] using IUP via dynamic linking
De: Mark Enviado: terça-feira, 21 de julho de 2020 15:40 Para: iup-users@lists.sourceforge.net Assunto: [Iup-users] using IUP via dynamic linking >The above works. But continuing, this fails: >im_dll = DLL_ROOT / 'libiupim.so' >im = ctypes.cdll.LoadLibrary(im_dll) At windows side, is libim.dll Are you sure, about libiupim.so name? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP Toolbar native support
Hi Scuri, I'm thinking of adding toolbar support to the applications. While looking at the example on iupvled, I would like to ask. There is native support on Windows, GTK and Motif for native toolbar, is there any special reason for not implementing an IupToolbar? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP Toolbar native support
> Because a toolbar is simply a combination of current IUP elements. With a > simple IupHbox and IupButtons you can >quickly implement a toolbar. IupVled > toolbar and IupLuaScripter toolbar are examples. Ok, thank you. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP weird issues (DirectX)
Hi Scuri, The are some new issues with IUP. 1. With 2DDirectX enabled (with theme manifest actived) DatePick control not is drawed with same height of IupText. Must be fixed by set SIZE to "200x11", by example. 2. With 2DDirectX enabled (with theme manifest actived) (a) Size Windows, not the same with GDI sizes. (b) When set with: IupSetAttribute(dlg, "PLACEMENT", "MAXIMIZED"); But, when restore with: IupSetAttribute(dlg, "PLACEMENT", "NORMAL"); windows size is totally wrong (too smal). 3. IupMatrix BUTTON_CB, is exported? To implement PopUp menu context, need this: IupSetCallback(mat, "__OLD_BUTTON_CB", (Icallback) IupGetCallback(mat, "BUTTON_CB")); IupSetCallback(mat, "BUTTON_CB", (Icallback) iup_popupmenu_button_cb); To call original action BUTTON_CB. What is different from traditional callbacks? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.30
> We just released IUP version 3.30 > We would like to highlight some of the new features: > * New: WYSIWYG HTML editor support for IupWebBrowser. See EDITABLE > attribute documentation. > * New: EXTRATEXTid and EXTRATEXTWIDTH attributes for IupFlatTree. Thanks > to M. Voznesenskiy. > * Changed: pre-compiled binaries of the tools executables are now built > with Visual C++ 15 (Visual Studio 2019) >and they are NOT compatible with > Windows XP nor Windows Vista, only with Windows 7, 8 and 10. Although they > >can still be built from source to run on Windows XP/Vista. > * Several bug fixes > You can find the complete list of changes and files for download at: Thanks Scuri, regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP weird issues (DirectX)
> But IupMatrix also exports its own callbacks. For instance, you can use the > CLICK_CB or RELEASE_CB callbacks to >implement a popup menu. Ok, many thanks. regards, Ranier Vilela Em seg., 3 de ago. de 2020 às 13:47, Ranier Vilela mailto:ranier_...@hotmail.com>> escreveu: Hi Scuri, The are some new issues with IUP. 1. With 2DDirectX enabled (with theme manifest actived) DatePick control not is drawed with same height of IupText. Must be fixed by set SIZE to "200x11", by example. 2. With 2DDirectX enabled (with theme manifest actived) (a) Size Windows, not the same with GDI sizes. (b) When set with: IupSetAttribute(dlg, "PLACEMENT", "MAXIMIZED"); But, when restore with: IupSetAttribute(dlg, "PLACEMENT", "NORMAL"); windows size is totally wrong (too smal). 3. IupMatrix BUTTON_CB, is exported? To implement PopUp menu context, need this: IupSetCallback(mat, "__OLD_BUTTON_CB", (Icallback) IupGetCallback(mat, "BUTTON_CB")); IupSetCallback(mat, "BUTTON_CB", (Icallback) iup_popupmenu_button_cb); To call original action BUTTON_CB. What is different from traditional callbacks? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net<mailto:Iup-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP assorted issues (part II)
Hi Scuri, More issues with latest trunk. 1. src/iup_elempropdlg.c & operator is dangerous, need paranteses to clarify expression. 2. iup_flatscrollbar.c !show_transparent test is always true, can be secure removed. 3. src/iup_gauge.c Not sure, IupDrawEnd(ih); is missing call? 4. src/iup_image.c Nonsense code? Or is another logic? 5. src/win/iupwin_filedlg.c Optimized test is buffer (char *) is empty. 6. src/win/iupwin_touch.c Bug? ti->dwID? regards, Ranier Vilela iup_assorted_issues_part_ii.patch Description: iup_assorted_issues_part_ii.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues (part II)
7. src\win\iupwin_fontdlg.c (195)
height_pixels = logfont.lfHeight; <- reassigned value?
8. src\win\iupwin_key.c (105)
map[VK_OEM_PLUS].iupcode = LOWORD(MapVirtualKeyA(VK_OEM_PLUS,
MAPVK_VK_TO_CHAR));
map[VK_OEM_COMMA].iupcode = LOWORD(MapVirtualKeyA(VK_OEM_COMMA,
MAPVK_VK_TO_CHAR));
map[VK_OEM_MINUS].iupcode = LOWORD(MapVirtualKeyA(VK_OEM_MINUS,
MAPVK_VK_TO_CHAR));
map[VK_OEM_PERIOD].iupcode = LOWORD(MapVirtualKeyA(VK_OEM_PERIOD,
MAPVK_VK_TO_CHAR));
vars reassigned?
9. src\win\iupwin_list.c (1424)
WM_CLEAR and WM_CUT perform the same action?
10. srccontrols\matrix\iupmat_aux.c (136)
Test not make sense.
if (index == p->num)
{
if (p->num == p->num_noscroll)
{
/* did NOT go trough the "for" above */
offset = scroll_pos;
index = p->num_noscroll; <- same value?
If index == p->num and p->num == p->num_poscroll, index is equal
p->num_noscroll.
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely
De: Antonio Scuri Enviado: sábado, 4 de julho de 2020 16:28 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely > Fixed and committed to the SVN. Thanks for reporting. Thank you. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-3.29 WIndows compilation (msvc 2019 32bits), tecmakewin troubles
Hi Scuri, More troubles with IUP compilation: if [ ! -d dep ] ; then mkdir -p dep ; fi ! foi inesperado neste momento. ../tecmakewin.mak:1741: recipe for target 'dep' failed win-make[2]: *** [dep] Error 255 makefile:12: recipe for target 'iuplua' failed win-make[1]: *** [iuplua] Error 2 makefile:41: recipe for target 'iuplua5' failed win-make: *** [iuplua5] Error 2 The dep directory already exist, whay is complain? What is correct directory structure for dep? set NO_DEPEND=Yes is set. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.29 Possible leak at iupwin_font.c
Hi Scuri, There are a possible leak at (src/win/iupwin_font.c) At line 89, IUP call: fonts = (IwinFont*)iupArrayInc(win_fonts); To create room for the next font, but uses var i with count value. var i must be count + 1, otherwise will replace the last font, leaking last pointer font. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 Possible leak at iupwin_font.c
De: Ranier Vilela Enviado: sexta-feira, 10 de julho de 2020 16:12 Para: IUP discussion list. Assunto: [Iup-users] IUP 3.29 Possible leak at iupwin_font.c Attached patch try to fix. regards, Ranier Vilela fix_possible_leak_iupwin_font.patch Description: fix_possible_leak_iupwin_font.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP-.32.9 Windows compilation (msvc 2019 32bits)
Hi Scuri, Troubles with IUP compilation: ''; echo Tecmake: linking iupvled.exe ... c:/progra~2/mib055~1/2019/community/vc/tools/msvc/14.26.28801/bin/Hostx86/x86/link -nologo-incremental:no -machine:X86 -debug -MANIFEST:NO -subsystem:windows -out:../bin/Win32/iupvled.exe -LIBPATH:../../cd/lib/dll16 -LIBPATH:../lib/dll16 -LIBPATH:../../cd/lib/dll16 -LIBPATH:../../im/lib/dll16 -LIBPATH:../../ftgl/lib/dll16 -LIBPATH:../../freetype/lib/dll16 -LIBPATH:../../zlib/lib/dll16 -LIBPATH:c:/progra~2/wi3cf2~1/10/lib/10.0.18362.0/ucrt/x86 -LIBPATH:c:/progra~2/wi3cf2~1/10/lib/10.0.18362.0/um/x86 -LIBPATH:c:/progra~2/mib055~1/2019/community/vc/tools/msvc/14.26.28801/lib/x86 -LIBPATH:c:/progra~2/mib055~1/2019/community/vc/tools/msvc/14.26.28801/atlmfc/lib/x86 iupim.lib im_process.lib cdim.lib iupimglib.lib iup_scintilla.lib imm32.lib msimg32.lib iupglcontrols.lib iup_plot.lib cdcontextplus.lib cdgl.lib gdiplus.lib iupcontrols.lib iupweb.lib iupole.lib comsuppw.lib iupcd.lib iup.lib iupgl.lib iupstub.lib cd.lib im.lib ftgl.lib freetype6.lib zlib1.lib glu32.lib opengl32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib uuid.lib oleaut32.lib ole32.lib comctl32.lib ../obj/iupvled/Win32/iup_vled.obj ../obj/iupvled/Win32/iup_vled_imgs.obj ../obj/iupvled/Win32/vled_image_editor.obj ../obj/iupvled/Win32/iup.res MSVCRTD.lib(initializers.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflita com uso de outras bibliotecas; use /NODEFAULTLIB:library iup_vled.obj : error LNK2019: símbolo externo não resolvido, _iupClassInfoGetDesc, referenciado na função _multitext_dwell_cb iup_vled.obj : error LNK2019: símbolo externo não resolvido, _iupClassInfoShowHelp, referenciado na função _multitext_kf1_cb iup_vled.obj : error LNK2019: símbolo externo não resolvido, _iupLoadLed, referenciado na função _load_led iup_vled.obj : error LNK2019: símbolo externo não resolvido, _iupLayoutExportNamedImageListSetHandle, referenciado na função _vLedExport iup_vled.obj : error LNK2019: símbolo externo não resolvido, _iupLayoutExportNamedImageList, referenciado na função _vLedExport ..\bin\Win32\iupvled.exe : fatal error LNK1120: 5 externo não resolvidos ../tecmakewin.mak:1683: recipe for target '../bin/Win32/iupvled.exe' failed win-make[2]: *** [../bin/Win32/iupvled.exe] Error 1120 makefile:10: recipe for target 'do_all' failed win-make[1]: *** [do_all] Error 2 makefile:51: recipe for target 'iupvled' failed win-make: *** [iupvled] Error 2 regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP assorted issues (part III)
Hi Scuri, There are some news issues with IUP-3.29 1. Possible dereference null at functions iFlatTreeTextEditVALUECHANGED_CB and iFlatTreeTextEditKCR_CB (src/iup_flatree.c) Function iFlatTreeGetNode can return NULL, so, var nodefocus can be NULL 2. Uninitialized var used (src/win/iupwin_clipboard.c) Var len is used at iupwinStrToSystemLen 3. Argument cannot be negative (src/iup_classinfo.c) function IupGetClassCallback (line 288) can return negative number qsort(attr_names, cb_n, sizeof(char*), compare_names); // cb_n cannot be negative number here 4. Use after free (src/win/iupwin_image.c) If IMAGEDESTROY_CB is defined at line 889, a function call will be done by passing variable handle freed. cb function callback cannot use handle. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP iupDlgListDestroyAll refactored
De: Antonio Scuri
Enviado: sexta-feira, 29 de maio de 2020 13:12
Para: IUP discussion list.
Assunto: Re: [Iup-users] IUP iupDlgListDestroyAll refactored
> Because IupDestroy will also remove the dialog from that list and list->next
> will be invalid.
Like this, it worked without problems.
void iupDlgListDestroyAll(void)
{
int i, count = 0;
Ihandle** ih_array = (Ihandle**)malloc(idlg_count * sizeof(Ihandle*));
Idiallst *list;
for (list = idlglist; list; list = list->next)
{
if (iupObjectCheck(list->ih))
{
ih_array[count] = list->ih;
++count;
}
}
for (i = 0; i < count; ++i)
{
IupDestroy(ih_array[i]); /* this will also destroy the list */
}
free(ih_array);
}
Advantagens:
1. Avoid assign variable count with i value;
2. Avoid call iupObjectCheck for every ih_array[i], since they have all been
verified.
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.29 Possible erros with iup_mglplot.cpp
Hi Scuri, Possible errors with iup_mglplot.cpp 1. line 97: error #40: expected an identifier !_Is_implicitly_default_constructible<_Uty1>::value || !_Is_implicitly_default_constructible<_Uty2>::value) 2. line 96: error #788: not a valid member class or function template declaration constexpr explicit( ^ 3. line 96: error #772: "explicit" is not allowed constexpr explicit( ^ 4. line 98: error #65: expected a ";" pair() noexcept( ^ 5. line 178: error #40: expected an identifier explicit piecewise_construct_t() = default; regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 Possible erros with iup_mglplot.cpp
Please, disregard that message. Wrong diagnostics. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP assorted issues (part IV)
Hi Scuri, Here some new issues with IUP. 1. Memory corruption at src/iup_draw.c variable points has size of 6, but call Polygon with only size 3. iupdrvDrawPolygon call msvc Polygon function 2. Memory corruption at srcglcontrols/iup_gldraw.c variable points has size of 6, but call Polygon with only size 3. iupGLDrawPolygon call msvc Polygon function 3. Possible division by zero at srcglcontrols/iup_gldraw.c variable sb_range can be zero regards, Ranier Vilela assorted_issues_part_iv.patch Description: assorted_issues_part_iv.patch ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues
De: Antonio Scuri Enviado: quarta-feira, 1 de julho de 2020 22:22 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP assorted issues > Just commited to the SVN. Thanks for the report and fixes. You are welcome. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues (part II)
De: Antonio Scuri Enviado: terça-feira, 7 de julho de 2020 18:05 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP assorted issues (part II) > All changes committed to the SVN. Thank you. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely
De: Ranier Vilela
Enviado: quinta-feira, 18 de junho de 2020 18:26
Para: IUP discussion list.
Assunto: [Iup-users] IUP 3.29 possible regression (IupMessage hide app
completely
>Maybe has a possible regression with IUP 3.29, regarding IUP 3.25 (last used).
>IupMessage, hide app completely, after click ok button.
>IUP 3.29
>Win32_DLL15_lib
>Windows 10 64 bits (2004)
>app msvc 2019 (64 bits)
Here a example:
int iup_message_cb(Ihandle * ih)
{
IupMessage("Message", "Message Example");
return IUP_DEFAULT;
}
int main(int argc, char ** argv)
{
Ihandle * vdlg;
Ihandle * window1;
Ihandle * txt_historic;
Ihandle * btn_msg;
IupOpen(, );
IupSetGlobal("UTF8MODE", "YES");
IupSetLanguage("PORTUGUESE");
txt_historic = IupText(NULL);
IupSetAttribute(txt_historic, "NAME", "txt_historic");
IupSetAttribute(txt_historic, "NUMBER", "YES");
IupSetAttribute(txt_historic, "SIZE", "80");
btn_msg = IupButton("Message", "btn_msg");
IupSetAttribute(btn_msg, "NAME", "btn_msg");
IupSetCallback(btn_msg, "ACTION", (Icallback) iup_message_cb);
vdlg = IupVbox(txt_historic, btn_msg, NULL);
window1 = IupDialog(vdlg);
IupSetAttribute(window1, "SIZE", "320x320");
IupShow(window1);
IupMainLoop();
IupClose();
return 0;
}
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.29 possible regression (IupMessage hide app completely
Hi Scuri, Maybe has a possible regression with IUP 3.29, regarding IUP 3.25 (last used). IupMessage, hide app completely, after click ok button. IUP 3.29 Win32_DLL15_lib Windows 10 64 bits (2004) app msvc 2019 (64 bits) regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely
De: Ranier Vilela Enviado: quinta-feira, 18 de junho de 2020 18:44 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely >IUP 3.29 >Win32_DLL15_lib >Windows 10 64 bits (2004) >app msvc 2019 (64 bits) Correcting: Windows 10 64 bits (2004) IUP 3.29 (32 bits) Win32_DLL15_lib (32 bits) app msvc 2019 (32 bits) regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely
De: Ranier Vilela Enviado: sexta-feira, 19 de junho de 2020 02:00 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely >Can you please, test, this debug version? >https://1drv.ms/u/s!AjvmIxxSzAeCgiEDb_H5mhmik8VA?e=66K4VJ Back to IUP 3.27, unfortunately. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 Possible leak at iupwin_open.c
De: Antonio Scuri Enviado: quinta-feira, 25 de junho de 2020 20:59 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP 3.29 Possible leak at iupwin_open.c > Ok, I'll check. But why iupwinShowLastError is being called? It is not > called by any IUP function... It is there for >debugging purposes only. > The example in FormatMessage doc is quite clear: >https://docs.microsoft.com/en-us/previous-versions/aa908810(v=msdn.10) Interestingly, I don't call this function directly, anywhere. I am using the IUP-3.27 release libraries. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.29 Possible leak at iupwin_open.c
Hi Scuri, DrMemory, still report leak at iupwinShowLastError function. Error #4: LEAK 264 direct bytes 0x03d1d250-0x03d1d358 + 0 indirect bytes # 0 replace_RtlAllocateHeap [d:\drmemory_package\common\alloc_replace.c:3771] # 1 combase.dll!InternalTlsAllocData +0x33f(0x759dbd30 ) # 2 combase.dll!InternalTlsAllocData +0xc3 (0x759dbab4 ) # 3 combase.dll!CoInitializeEx +0x34 (0x7595b185 ) # 4 iup.dll!iupwinShowLastError +0xe5 (0x69adfff6 ) # 5 iup.dll!IupOpen +0x4d4(0x69aa23e5 ) Now, most interestingly, it is the function he reports that has been replaced for testing. AllocateHeap Perhaps Microsoft's documentation is wrong and the correct function for freeing memory allocated by FormatMessage is FreeHeap. See at: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa374721(v=vs.85) Can you test, replace LocalFree for FreeHeap? I still, can not compile IUP here. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely
De: Antonio Scuri Enviado: quinta-feira, 18 de junho de 2020 19:05 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP 3.29 possible regression (IupMessage hide app completely > I ran your sample code here and it worked, the main dialog does not hide. But > when I run from inside Visual Studio >when I click OK the main dialog goes > behind the visual studio window. Running outside VS this does not occur. I'm > >using VS 2017. Can you please, test, this debug version? https://1drv.ms/u/s!AjvmIxxSzAeCgiEDb_H5mhmik8VA?e=66K4VJ regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP 3.29 Possible leak at iupwin_open.c
De: Ranier Vilela Enviado: quinta-feira, 25 de junho de 2020 21:01 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP 3.29 Possible leak at iupwin_open.c >Interestingly, I don't call this function directly, anywhere. >I am using the IUP-3.27 release libraries. The call origin is from IupOpen(NULL, NULL); regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Moore, Tysen Enviado: sexta-feira, 5 de junho de 2020 16:10 Para: IUP discussion list. Assunto: Re: [Iup-users] Fw: IUP License Questions >I'm not sure I entirely agree with your statement: "The point here is that IUP >project have nothing to do with it all. >After all, who is possibly violating >the GPL is the end user of the libraries (CD and IM). The IUP project only >provides, >as a courtesy, the source code of the GPL libraries to anyone who >wants to use it or not, it does not oblige in any >way to use them. And it is >clearly documented, including licenses, in its official documentation, so that >no one is in >doubt." Welcome to the opensource world, with the GPL. >I agree that all users are ultimately responsible for the licenses used within >their projects. However, please take a >step back and look at this as a new >IUP user like myself. I started my project by evaluating a number of >>cross->platform frameworks: wxWidgets, Qt, NCurses, Nuklear, IUP. When >evaluating a number of frameworks I >relied on top level docs, and I even >wrote the same simple app to evaluate high level features needed by my >>application. We decided to use IUP because of its: ease of use, feature set, >licensing, etc. I think it is a little naive to >think a new user evaluating >a framework will know to look for third party licenses in every source >directory when >the top level overview/license sections indicate it's "free >software, can be used for public and commercial >applications". I believe >that you feel things are "clearly documented" but this is from your intimate >knowledge of >the framework. As a new user this is not the case. It is even >more confusing for a new user because the IUP/etc >directories make no clear >distinction between third-party and IUP framework code--at least for a new >user. Unfortunately it is confusing yes. What has to be made clear here, is about the IUP License, is that they are talking about the code itself. It's free-code, without any restrictions. But, as a developer, you and I have to really check if what we are going to use is free or not. That is why I do not use the CD library in my products. See, I already found, for example, projects with all free libraries (not GPL), but the final project is GPL, that is, in this case, you can use the libraries in non-free products, but not the main product code , very confused. >My reasoning for my initial email was not to cause a big fight in this list. >I was bringing this to the attention of the >list in case the maintainers or >users were unaware of these issues. I was also looking for some guidance for >best >practices to resolve these issues. My suggestion was for a benign >change to the top level docs to clearly list third >party code that one should >be aware of. If the maintainers of IUP don't want to do this, that is their >decision. >Again, my thought was a suggestion for [apparently debatable] >improvement. No harm. Certainly, a welcome suggestion, not an imposition. But Tecgraf cannot be held responsible for any deviations that may occur, with or without warnings, by whoever uses the libraries, because in the end, it is not Tecgraf that is violating the GPL, after all the products distributed by it are free-code (GPL accordance). Better yet, walk the path of removing all GPL libraries, step by step, in the end, indirectly protecting all users of those libraries, who may want to create non-free products. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Richard Stallman Enviado: sábado, 6 de junho de 2020 03:56 Para: Ranier Vilela Cc: arobinso...@cox.net; iup-users@lists.sourceforge.net Assunto: Re: [Iup-users] Fw: IUP License Questions [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] >> The point here is that IUP project have nothing to do with it all. >> After all, who is possibly violating the GPL is the end user of >> the libraries (CD and IM). >I do not know the facts of this, but it sounds like the developers of IUP >are encouraging users to link UUP together with GPL'd libraries. >That may be infringement. I cannot agree with that statement. What if I, as a developer, want to create free code, based on the work distributed by the IUP project? Wouldn't I be benefiting, from all the work already done, wouldn't I be complaining, or criticizing, or saying that this is a shame? But if, on the contrary, as a developer, I want to create non-free code, based on someone's work, whoever it is, it is necessary, very careful and a lot of careful research, so as not to violate the GPL. >Does IUP tell users that they can't link IUP and those GPL'd libraries >into one combined program? Are we talking about children? A project, is it necessary to take hands and cross the street? For more than 20 years, I know that I cannot combine GPL to create non-free code, even though I call it a commercial product (wrongly). It is not in the assignments of any projects, to say what users can and cannot do, with respect to GPL. The project itself does not violate the GPL in any way. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Source code license comments; IUP/CD/IM notes
De: helen.wri...@atiras.com Enviado: domingo, 7 de junho de 2020 12:32 Para: 'IUP discussion list.' Assunto: Re: [Iup-users] Source code license comments; IUP/CD/IM notes >Is there any way on this mailing list to filter out conversations that one has >not interest in. Or which are just >descending into name calling? Sorry for that. Unfortunately, collaborating is not for everyone. best regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Andrew Robinson Enviado: quarta-feira, 3 de junho de 2020 17:11 Para: Richard Stallman Cc: IUP discussion list. Assunto: Re: [Iup-users] Fw: IUP License Questions >So far, this is how many products I had no idea from the IUP documentation >cannot be used for public or commercial applications (unless you open source >your public or commercial application): > FFTW > MiniLZO > Tuio >PdfLib >FGTL >Freetype > Zlib > Scintilla > WinDrawLib Once you don't know it, I'll read it to you. FFTW is GPL, and not can be use with commercial closed products. MiniLZO is GPL and no can be use with commercial closed produtcs. PDFlite (PDFLib) is GPL and no can use with commercial closed produtcs. Tuio is LGPL and can be use with commercial closed products. http://reactivision.sourceforge.net/ "The related TUIO reference implemenations and clients are available under the LGPL, license which both allows its inclusion in open and closed source projects, while only the changes to the actual libraries need to be published under the same LGPL license." FFTW, MiniLZO and PDFlite, is not used in IUP framework. So IUP users can use with commercial products legal rightfully. CD framework and IM framework is another history and must be evaluated by whoever will use it, excluding GPL libraries that cannot be used in commercial products, without the purchase of the proper license. >Let me know if I should escalate this issue to someone else if this is not >something you want to deal with because I don't want to waste your time or >mine. Do the list a favor, stop wasting our time and get out of it. +1 for remove from the list. Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Antonio Scuri Enviado: quinta-feira, 4 de junho de 2020 21:42 Para: IUP discussion list. Assunto: Re: [Iup-users] Fw: IUP License Questions > Actually we can implement a CD_HARU_PDF driver. That will be a nice > alternative for PDFLib. Would be excellent. Thanks. > BTW we already have a CD_CAIRO_PDF driver implemented. But it depends on > Cairo. Cairo is LGPL and can be used with commercial products (non-free-code). https://www.cairographics.org/ regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Hernan Cano Enviado: quinta-feira, 4 de junho de 2020 19:32 Para: IUP discussion list. Assunto: Re: [Iup-users] Fw: IUP License Questions >>> IUP library does not use PDFLite. >>> CD library uses PDFLite. >Thanks for clarification. As my interest is "using Lua language with IUP >grafical interface --and CD and IM attached >to IUP--", I wrote about IUP as >the "main" of the package. But... yes... thanks. You are welcome. >And yes, I have seen the PDFLite license, and I agree. >And since the point of view of mine, I cannot use LibHaru,because I understand >you that this proposal of you >involves "put my fingers in IUP core and/or CD >core and/or IM core" and this is something not relsated with me, >just using >Lua+IUP+CD+IM, not to program its core. Of course, no problem. But libharu is a viable alternative to the CD library, it is free and in my opinion better than PDFLite. >But I'll take a look on LibHaru. Maybe, has lua package... regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Andrew Robinson Enviado: quarta-feira, 3 de junho de 2020 19:36 Para: Antonio Scuri Cc: IUP discussion list.; Richard Stallman Assunto: Re: [Iup-users] Fw: IUP License Questions Hello Antonio, On 2020-06-03 at 10:45 AM, Antonio Scuri mailto:antonio.sc...@gmail.com>> wrote: > I agree with mr Stallman, but I totally disagree with you when you say: >And I agree with Tysen Moore and his lawyers. >"That got my attention because I don't like surprises, so then >Tysen and I both asked Mr Scuri why no mention of this was made in either the >licensing section or in the credit section, he basically said you had to go >find it yourself somewhere within the source code." >I clearly said I clearly said that our secondary libraries are documented in each respective page that states they are >NOT part of our main library. Their licenses are described there. If our secondary library uses a third party library that >is GPL code then this secondary library is also GPL. That's exactly why we left it in a secondary library and NOT in the >main library. Even though all our code is open source and available to everyone use and modify. >"I clearly said...". >We asked for links and you clearly gave none. We asked for examples and you >clearly gave none. That's not being >"clear", that is being evasive. All I'm >asking for (and all I can see that Tysen Moore is asking for), is to pretty >please >include ALL the licenses that the IUP project bundles with IUP, and >put them in one easy-to-find place like the >copyright or credits section of >the IUP WebBook. I don't want to see any more emails about lawyers having an >excuse >to find questionable things in IUP anymore -- agreed? >FYI, I looked at IupTuioClient() and there is no mention of any 3rd party >license. Is that because there is none? Or >maybe the license is buried >somewhere in the source code (something that I am not directed or required to >read or >download in the IUP documentation/WebBook)? Linking to the license on >the Internet in an email or saying the >license is somewhere in the source >code, is not including the license in the documentation as the licenses appear >to >say they must do. The WebBook is required documentation therefore that is >where ALL the licenses by default should >be mentioned, as other companies do. > The secondary libraries are OPTIONAL. If you don't understand that, please > don't use it at all. >Where in the IUP WebBook are any libraries/functions literally documented as >being "OPTIONAL" to IUP? This is all >brand new to me. >"In other words, the WHOLE TRUTH is, only a part of the IUP bundled-framework >can be used for public >commercial applications, unless you want to open source your application, but >they fail to tell you which parts are "completely free" and which are not." > You are not obligated to use all libraries available in IUP. If you use, > the least you can do is to read the >documentation of the library. >Then give a direct link to where IupTuioClient() in the IUP WebBook where it >clearly says it isn't a part of the IUP >licensing. I mean just as one example >of "the right thing to do". > This is your misunderstanding. IUP exists for more than 20 years. >One mistake in 20 years isn't something to be ashamed of, is it? >Several times it has been analyzed for use in commercial applications that are >not free. Our documentation is actually >one thing that I'm proud of, making >clear and being updated in detail for everyone. > Again if you do think this way, please simply don't use it. >I have a better idea: be more transparent about all the licensing requirements >of anything that is not actually a part >of the IUP licensing, as every other >company does. Don't make this more difficult than it has to be. I not agreed. First, No one is forced to do or fail to do something for you, is that CLEAR for you! Second, Everything that the IUP team does for users is nothing more than kindness. Third, if you don't agree with that, you're living in the world of the moon, it's simple, stop using. Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues
De: Antonio Scuri Enviado: segunda-feira, 1 de junho de 2020 16:50 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP assorted issues > Ok. I'll take a look. Thanks. Scuri, can we move to for whatever matters that really matter to IUP, Did you get a look at the patch? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Antonio Scuri Enviado: quinta-feira, 4 de junho de 2020 21:42 Para: IUP discussion list. Assunto: Re: [Iup-users] Fw: IUP License Questions > Actually we can implement a CD_HARU_PDF driver. That will be a nice > alternative for PDFLib. Taking the opportunity, I could not help suggesting, for the future of course, one more step. Replace FFTW by FFTSS (https://www.ssisc.org/fftss/index.html.en) Excerpt taken: "Key Features Compatibility with FFTW3. Replace the header file name "fftw3.h" with "fftw3compat.h". " regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Richard Stallman Enviado: sexta-feira, 5 de junho de 2020 03:17 Para: Ranier Vilela Cc: arobinso...@cox.net; iup-users@lists.sourceforge.net Assunto: Re: [Iup-users] Fw: IUP License Questions [[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > FFTW is GPL, and not can be use with commercial closed products. >> MiniLZO is GPL and no can be use with commercial closed produtcs. >What you say is right in the basic point, but not stated correctly. >The incorrect aspect is the use of the words "commercial" and >"closed". Yes, it's a little confusing. I understand that there may be a commercial product, with open source. >It is incorrect to use the word "commercial" here. The GPL does not >distinguish between commercial activities and noncommercial acivities, >except in one very obscure case which does not apply here. >it is incorrect to use the word "closed" here. We shun the terms >"open" or "closed" because we do NOT advocate "open source". That >term stands for rejecting our values and principles, so we have never >advocated it and never will. >See https://gnu.org/philosophy/open-source-misses-the-point.html >for more explanation of the difference between free software and open >source. >The right way to state this basic point is that the GPL permits >including the GPL-covered code in a larger combined program >_only provided that_ the larger combined program is, as a whole, >released under the GPL. >In particular, to combine a nonfree program with GPL-covered code >violates the GPL. Yes, I think we all understand that. The point here is that IUP project have nothing to do with it all. After all, who is possibly violating the GPL is the end user of the libraries (CD and IM). The IUP project only provides, as a courtesy, the source code of the GPL libraries to anyone who wants to use it or not, it does not oblige in any way to use them. And it is clearly documented, including licenses, in its official documentation, so that no one is in doubt. >I don't have time to study the details of this case. >I can't keep up with my work now. Anyway, thank you very much for your clarification. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP License Questions
De: Andrew Robinson Enviado: terça-feira, 2 de junho de 2020 01:45 Para: Antonio Scuri; r...@gnu.org Cc: IUP discussion list. Assunto: Re: [Iup-users] IUP License Questions >I see only one download for IUP, not many. Those who use the IUP libraries, in dynamic DLL and who do not use any 3rd libraries depending on GPL, are legal. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues
De: Andrew Robinson Enviado: quarta-feira, 3 de junho de 2020 23:23 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP assorted issues >so I'm ignoring you from now on. Please, do me this favor. ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Fw: IUP License Questions
De: Hernan Cano Enviado: quinta-feira, 4 de junho de 2020 03:23 Para: IUP discussion list. Assunto: Re: [Iup-users] Fw: IUP License Questions >I am very interested in using Lua and IUP and addings, not just for learning >(that I am doing for these days), but for >commercial products (I wait very >soon). >But it is clear that one must no use illegally any one of the referred >libraries. >I thank you that you share the things you have found. >Can you share me where can I find info about PDFLite license (since IUP point >of view and since PDFLib point of >view) for me to deep into it? https://www.pdflib.com/licensing-support/ IUP library does not use PDFLite. CD library uses PDFLite. Unfortunately, if you choose to use IUP with CD, to have access to PDFLite, you will have to purchase the license to use PDFLite in order to use it with a commercial product (non-free code). Alternatively, it could help to develop a version for use with libharu whose license is BSD. https://github.com/libharu/libharu/wiki/FAQ regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP License Questions
De: Andrew Robinson Enviado: terça-feira, 2 de junho de 2020 01:45 Para: Antonio Scuri; r...@gnu.org Cc: IUP discussion list. Assunto: Re: [Iup-users] IUP License Questions >I see only one download for IUP, not many. The GPL license appears to say that >ALL code linked with GPL source >(that would mean all the GPL static >libraries), must also be disclosed under a GPL license. By providing GPL >static >libraries in a single IUP package instead of having the users download >it separately (which is what "split" would >actually mean), it seems to me >that it might a violation of the GPL license. >But I'm not a lawyer or the author of GPL, so maybe someone else can tell us >if this is legit? Maybe someone like >Richard Stallman, which Google lists as >the author of GPL? Resume: 1. FGTL (LGPL), legal use with DLL or STATIC https://sourceforge.net/projects/ftgl/ 2. Freetype (BSD), legal use with DLL or STATIC https://sourceforge.net/projects/freetype/ 3. Zlib (BSD), legal use with DLL or STATIC https://zlib.net/zlib_license.html 4. Scintilla (BSD), legal use with DLL or STATIC https://www.scintilla.org/License.txt 5. Math Graphics Library (MIT), legal use with DLL or STATIC http://glm.g-truc.net/copying.txt 6. WinDrawLib (BSD), legal use with DLL or STATIC https://github.com/mity/windrawlib Conclusion, who use IUP library, it is perfectly legal and can be used with commercial software. This answer your question? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupProgressBar
De: supp...@scriptbasic.org Enviado: quinta-feira, 16 de julho de 2020 00:59 Para: IUP discussion list. Assunto: Re: [Iup-users] IupProgressBar >It looks like you only get the DASHED look if you don't use visual >styles. (default) Can you confirm this? It looks like, when checking the code. if (!iupwin_comctl32ver6 && !iupAttribGetBoolean(ih, "DASHED")) dwStyle |= PBS_SMOOTH; Windows DASHED gauge, works with visual styles? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IupList Behavior (Windows)
Hi Scuri, Two questions about IupList with Windows. DROPDOWN=YES EXPAND=HORIZONTAL 1. Mouse moviment behavior: When move mouse to end control, Windows automatically, scroll items to down. Is possible control the speed? Is possible control the number of items, that will be scrolled? 2. MSDN says: https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousemove "If an application processes this message, it should return zero." At src/win/iupwin_list.c (1557) WM_MOUSEMOVE: is processed, but IUP lacks to return zero, why? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupProgressBar
De: supp...@scriptbasic.org Enviado: quinta-feira, 16 de julho de 2020 03:12 Para: IUP discussion list. Assunto: Re: [Iup-users] IupProgressBar >My interface is calling IUP dynamically via FFI. ScriptBasic >(interpreter) is providing style support and other Windows resouces. >My FFI is only working with IUP.DLL and IUPCONTROLS.DLL. >I'm not sure what you're asking me to call to get this to work. Regardless of the tools we use, there is what works in Windows and what doesn't. And there is Microsoft documentation. If we want to correct something that doesn't work, we can indicate to the team, in the documentation, which is the correct way to use the resource. In this particular case, we need to find out if the use of the gauge is in accordance with the documentation. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues (part IV)
De: Antonio Scuri Enviado: quinta-feira, 16 de julho de 2020 18:33 Para: IUP discussion list. Assunto: Re: [Iup-users] IUP assorted issues (part IV) >> 1. Memory corruption at src/iup_draw.c >> variable points has size of 6, but call Polygon with only size 3. >> iupdrvDrawPolygon call msvc Polygon function > Count is the number of points, not the size of the array. Why Coverity claims this? 4. access_dbuff_in_call: Calling Polygon indexes array (POINT *)points with index count. See this example: http://www.functionx.com/visualc/gdi/polygons.htm CPoint Pt[7]; Pt[0] = CPoint(20, 50); Pt[1] = CPoint(180, 50); Pt[2] = CPoint(180, 20); Pt[3] = CPoint(230, 70); Pt[4] = CPoint(180, 120); Pt[5] = CPoint(180, 90); Pt[6] = CPoint(20, 90); pDC->Polygon(Pt, 7); // Msvc Polygon call function Maybe this issue is: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-polygon Polygon expect param const POINT *apt; and IUP uses array type int? >> 2. Memory corruption at srcglcontrols/iup_gldraw.c >> variable points has size of 6, but call Polygon with only size 3. >> iupGLDrawPolygon call msvc Polygon function > Same >> 3. Possible division by zero at srcglcontrols/iup_gldraw.c >> variable sb_range can be zero >If range is zero the scrollbar is not displayed, so that function is never called. But I added a test. Thanks. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupList Behavior (Windows)
De: Antonio Scuri Enviado: quinta-feira, 16 de julho de 2020 18:42 Para: IUP discussion list. Assunto: Re: [Iup-users] IupList Behavior (Windows) >> 1. Mouse moviment behavior: >> When move mouse to end control, Windows automatically, scroll items to down. >> Is possible control the speed? > Not that I know of. Ok. >> Is possible control the number of items, that will be scrolled? >What you can control is the number of visible items with the VISIBLEITEMS attribute. But the scroll depends on the >ratio of total items x visible items, and I think that scrollbar is not configurable by the application. >>2. MSDN says: >>https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousemove >>"If an application processes this message, it should return zero." >>At src/win/iupwin_list.c (1557) >>WM_MOUSEMOVE: is processed, but IUP lacks to return zero, why? > In the general case, yes it must return 0. But in this case we are sharing > the processing of WM_MOUSEMOVE with >the internal COMBOBOX implementation, > so notice that we will leave that processing for the control original > >WinProc. Thanks Scuri, regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues (part IV)
De: Antonio Scuri
Enviado: quinta-feira, 16 de julho de 2020 18:50
Para: IUP discussion list.
Assunto: Re: [Iup-users] IUP assorted issues (part IV)
>> Why Coverity claims this?
>> 4. access_dbuff_in_call: Calling Polygon indexes array (POINT *)points with
>> index count.
>> Polygon expect param const POINT *apt;
>> and IUP uses array type int?
>Yes, it is.
Well, Polygon expect variable type CPOINT:
https://docs.microsoft.com/en-us/previous-versions/dd162805(v=vs.85)
typedef struct tagPOINT {
LONG x;
LONG y;
} POINT, *PPOINT;
I believe, that can corrupt memory.
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IupList extended behavior (find string)
Hi Scuri, I would like suggest a new feature to IUPList: Actually normal behavior (Windows) is find a ITEM by first letter only. Extended behavior when user type a text. Find a ITEM by users type text (invisible buffer) Windows can use CB_FINDSTRING message GTK (?) Motif (?) Example: Windows normal behavior: Item 1: Red Item 2: White Item 3: Gray Item 4: Green If user type G, Windows ComboBox select the item 3 (only first G) Extended behavior: If user type Gre, Windows ComboBox select the item 4 What do you think? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues (part IV)
De: Antonio Scuri
Enviado: quinta-feira, 16 de julho de 2020 19:00
Para: IUP discussion list.
Assunto: Re: [Iup-users] IUP assorted issues (part IV)
> Yes, there are two integers there. And we provide an array with twice the
> size, but count still contains just the >number of points. It is correct.
IMHO, I can't see how this can work.
#include
typedef struct CPOINT {
long x;
long y;
} POINT, *PPOINT;
void cast_to_point(int * ipoints, int count)
{
POINT * cpoints;
int i;
cpoints = (POINT*) ipoints;
for(i = 0; i < count; ++i) {
printf("cpoints[%d]->x=%ld\n", i, cpoints[i].x);
printf("cpoints[%d]->y=%ld\n", i, cpoints[i].y);
}
}
int main()
{
int ipoints[6];
ipoints[0] = 180;
ipoints[1] = 50;
ipoints[2] = 180;
ipoints[3] = 20;
ipoints[4] = 230;
ipoints[5] = 70;
cast_to_point(ipoints, 3);
}
output:
cpoints[0]->x=214748364980
cpoints[0]->y=85899346100
cpoints[1]->x=300647710950
cpoints[1]->y=0
cpoints[2]->x=0
cpoints[2]->y=135050311015237
I think is better declare a struct point for the IUP use.
typedef struct IUP_POINT {
long x;
long y;
} point_t,;
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IUP assorted issues (part IV)
De: Antonio Scuri
Enviado: quinta-feira, 16 de julho de 2020 22:36
Para: IUP discussion list.
Assunto: Re: [Iup-users] IUP assorted issues (part IV)
> This is the output here:
>cpoints[0]->x=180
>cpoints[0]->y=50
>cpoints[1]->x=180
>cpoints[1]->y=20
>cpoints[2]->x=230
>cpoints[2]->y=70
Oh yes, OK.
> But it is system dependent. Because "long" in Visual C++ will be the same as
> "int".
> In which system did you test?
http://cpp.sh/
With long type, works.
#include
typedef struct CPOINT {
long x;
long y;
} POINT, *PPOINT;
void cast_to_point(long * ipoints, int count)
{
POINT * cpoints;
int i;
cpoints = (POINT*) ipoints;
for(i = 0; i < count; ++i) {
printf("cpoints[%d]->x=%ld\n", i, cpoints[i].x);
printf("cpoints[%d]->y=%ld\n", i, cpoints[i].y);
}
}
int main()
{
long ipoints[6];
ipoints[0] = 180;
ipoints[1] = 50;
ipoints[2] = 180;
ipoints[3] = 20;
ipoints[4] = 230;
ipoints[5] = 70;
cast_to_point(ipoints, 3);
}
output:
cpoints[0]->x=180
cpoints[0]->y=50
cpoints[1]->x=180
cpoints[1]->y=20
cpoints[2]->x=230
cpoints[2]->y=70
Maybe, can changed to long?
Is secure to GTK and Motif?
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupGetAllAttributes C question
>I have some basic code in C that creates a couple of elements and tries to
>print out the list of attributes associated >with one of them (a text area in
>the example below), but when I run it, all the attribute names I expected to
>see are >NULL even though IupGetAllAttributes said there would be several (7
>in this example). I must be doing something >obviously wrong, and to be
>honest, I've forgotten most of programming in C...
>Any ideas one what I'm doing wrong here?
I don't sure if is related, but when GUI, the things is different from linear
execution.
Try:
IupMainLoop();
before print attributes.
#include "iup.h"
#include
#include
#include
int main(int argc, char** argv) {
IupOpen(argc, argv);
Ihandle *text = IupText(NULL);
IupSetAttribute(text, "MULTILINE", "YES");
IupSetAttribute(text, "EXPAND", "YES");
Ihandle *button = IupButton("Press me", NULL);
Ihandle *box = IupVbox(text, button, NULL);
Ihandle *dialog = IupDialog(box);
IupSetAttribute(dialog, "SIZE", "320x200");
IupShow(dialog);
IupMainLoop();
int names_count = IupGetAllAttributes(text, NULL, -1);
printf("attribute count: %d\n", names_count);
char **names = calloc(names_count, sizeof(char*));
IupGetAllAttributes(text, names, names_count);
for (int i = 0; i < names_count; i++) {
printf("attribute: %s\n", names[i]);
}
IupClose();
}
regards
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] IupList extended behavior (find string)
> Yes, that could be very interesting. I'm closing a new version now. We could > plan it for the next version. Great, how can I help? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP Drag support
Hi Scuri, Do you know if IUP supports drag & drop between different applications? Drag application (Windows Paint) Drop application (IupCanvas) It's possible? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Ubuntu ARM 64 - vertical RASTERSIZE not working
De: supp...@scriptbasic.org Enviado: quarta-feira, 21 de abril de 2021 21:35 Para: IUP discussion list. Assunto: Re: [Iup-users] Ubuntu ARM 64 - vertical RASTERSIZE not working >It seems that 'hot keys' (underlined character with the & preceding it) >doesn't work with Gtk Linux IUP either. >This is becoming VERY disappointing! I am sure that IUP will be very happy to receive patches. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] First use of IupImgLib.dll
Hi Scuri, First use of IupImgLib.dll Error message: "Não foi possível localizar o ponto de entrada do procedimento IupLsOpened na biblioteca de vinculo dinamico iupimaglib.dll" iup-3.30_Win32_dll16_lib.zip Any idea what's wrong? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] First use of IupImgLib.dll
De: Ranier Vilela Enviado: quarta-feira, 28 de abril de 2021 22:51 Para: IUP discussion list. Assunto: [Iup-users] First use of IupImgLib.dll >Hi Scuri, >First use of IupImgLib.dll >Error message: >"Não foi possível localizar o ponto de entrada do procedimento >IupLsOpened na biblioteca de vinculo dinamico >iupimaglib.dll" >iup-3.30_Win32_dll16_lib.zip >Any idea what's wrong? It seems to me that iupimglib, is failing to import the reference to function IupIsOpened or Iup library is failing to export it. regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Issue with iup.list and showdragdrop
De: Scott Morgan via Iup-users Enviado: quinta-feira, 15 de abril de 2021 13:35 Para: iup-users@lists.sourceforge.net Cc: Scott Morgan Assunto: Re: [Iup-users] Issue with iup.list and showdragdrop On 14/04/2021 22:54, Ranier Vilela wrote: > De: Scott Morgan via Iup-users >> >> Further examination suggests the problem is around src/win/iupwin_list.c >> line 1098. > >> The result of winListGetItemData isn't checked (returns NULL in this >> situation) and immediately used on the next line (itemdata->hBitmap) > > Correct, winListGetItemData can return NULL. > It's needed protect itemdata against NULL. > >Should I file a ticket somewhere? No. That is on that list. Scuri is responsible for the development team. Unfortunately it is absent for some time. Is everything okay Scuri? I wish you are well, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Ubuntu ARM 64 - vertical RASTERSIZE not working
De: supp...@scriptbasic.org Enviado: quarta-feira, 21 de abril de 2021 04:49 Para: IUP discussion list. Assunto: Re: [Iup-users] Ubuntu ARM 64 - vertical RASTERSIZE not working >Here are a couple screen shots of my Windows 10 (good) and Ubuntu 20.04 >(bad) IUP layouts. Which version of GTK is used? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Ubuntu ARM 64 - vertical RASTERSIZE not working
De: supp...@scriptbasic.org Enviado: quarta-feira, 21 de abril de 2021 04:49 Para: IUP discussion list. Assunto: Re: [Iup-users] Ubuntu ARM 64 - vertical RASTERSIZE not working >Here are a couple screen shots of my Windows 10 (good) and Ubuntu 20.04 >(bad) IUP layouts. A simple and probably wrong guess. In ARM64 (Ubuntu 20.04), the window size is very small, to properly draw widgets? regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] Issue with iup.list and showdragdrop
De: Scott Morgan via Iup-users
Enviado: quarta-feira, 14 de abril de 2021 15:40
Para: iup-users@lists.sourceforge.net
Cc: Scott Morgan
Assunto: Re: [Iup-users] Issue with iup.list and showdragdrop
On 14/04/2021 15:47, Scott Morgan via Iup-users wrote:
> Running into an issue with IUP unexpectedly exiting app
>
> Simple Lua script:
>
> dlg = iup.dialog{iup.list{expand="YES",showdragdrop="YES"}}
> dlg:showxy(iup.CENTER,iup.CENTER)
> iup.MainLoop()
>
> Now click on the lower area of the list box (below the empty list item
> placeholder), the executable quits without warning.
>
> Remove the showdragdrop setting and everything works fine.
>
> This is on Win10.
>Further examination suggests the problem is around src/win/iupwin_list.c
>line 1098.
>The result of winListGetItemData isn't checked (returns NULL in this
>situation) and immediately used on the next line (itemdata->hBitmap)
Correct, winListGetItemData can return NULL.
It's needed protect itemdata against NULL.
regards,
Ranier Vilela
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] IUP 3.30 misses functions prototypes
Hi Scuri, The functions below do not have prototypes declared. void IupSetRGBA(Ihandle* ih, const char* name, unsigned char r, unsigned char g, unsigned char b, unsigned char a); void IupGetRGBA (Ihandle* ih, const char* name, unsigned char *r, unsigned char *g, unsigned char *b, unsigned char *a); Which causes the following error message: "Could not find entry point for IupGetRGBA procedure in dynamic link library" regards, Ranier Vilela ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
