iup-users — IUP Discussion List

Re: [Iup-users] Are you ok?

[Antonio S. <ant...@gm...>]

  Thanks Andrew! Yes, I'm ok.

  Sorry for being away from IUP, but it's been very hard to keep up with my
current tasks.

  Hope to get back soon.

Best,
Scuri


Em seg., 15 de mai. de 2023 às 20:08, Anonymous <ano...@gm...>
escreveu:

> Ola Antonio Scuri,
>
> Haven't heard from you in awhile. Is everything ok? Do you need any help?
>
> Signed,
> Andrew
>
> PS -- I apologize for using your email address instead of the users
> list, but I don't think this was appropriate posting on the users list.
>
>

[Iup-users] [ANN] lglicua-0.1-alpha7 has been released...

[sur-behoffski <sur...@gr...>]

G'day,

I've just released revision "0.1-alpha7" of lglicua, my project to
extend the availability of the Tecgraf IM/CD/IUP projects on SourceForge,
that were originally advertised as being available for source compilation
on "Windows and Ubuntu".

--

As before, a pop-up graphical message box, saying "hello, world", can
be achieved in just two lines of a Bash+Lua script:

        #!/bin/bash ../support/play-lua-tec
        iup=require("iuplua"); iup.Message("MyApp", "hello, world")

--

A key feature of this Assistant is that it works from the latest
Subversion repository, instead of the bundled releases.  In particular
(release SVN revisions have been inferred from repository activity):

        IM:  Release 3.15, SVN r816,  2020-07-30 (now r820);
        CD:  Release 5.14, SVN r894,  2020-07-31 (now r901); and
        IUP: Release 3.30, SVN r5892, 2020-08-02 (now r5947).

--

Any one, or more, of Lua 5.1, 5.2, 5.3 and 5.4 can be installed.
The installer lets the user switch the currently-active Lua version
using an "Alternatives" mechanism, inbuilt in Debian/Ubuntu Distros,
and emulated on Red Hat Distributions.

--

I've upgraded LuaRocks so that the latest version, 3.9.2, is installed.
The current Lua version is used as the guide for the LuaRocks version
selections... but a reboot may be the easiest way to set up the
environment for the Lua+LuaRocks combination (LUA_PATH and LUA_CPATH,
as seen in in "luarocks --path --bin").

So, with some care/effort, a project may be compiled for different
versions of Lua, together with the Rocks environment.

--

Red Hat-style distributions that I've tested (all are x64):

    - CentOS7;
    - Rocky 9; and
    - Rocky 9.1.

Ubuntu (Debian)-style distributions that I've tested (all are x64):

    - GNU/Linux Mint 19.1;
    - GNU/Linux Mint 21;
    - GNU/Linux Mint 21.1;
    - Ubuntu 18.04.3;
    - Ubuntu 20.04.3;
    - Ubuntu 22.10;
    - MX21_ahs; and
    - MX21.1_ahs.

I tried to support MX21.3, but there some glitches that were too hard
or obscure to overcome quickly.

Along the way, I'm dropping old releases as the Vendor drops support:
LM19.1 will become unsupported within a few months.  Older
distributions may still work with the new -0.1-alpha7 code, but I
haven't tested them at all.

--

There's been some more work under the hood, which will hopefully show
progress more clearly, and improve retry/fail strategies in a couple
of areas.

-------

You can find the project on SourceForge at:

        https://sourceforge.net/projects/lglicua/

The project can be downloaded as a tarball, or you can browse the
sources online in a Git repository.

Feedback is very welcome!


cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] [Patch:] Fix tecmake.mak for GNU/Linux Kernel 6 and 7.

[sur-behoffski <sur...@gr...>]

G'day,

Inspired by Scuri's promise of an impending IUP release late
last year, I took it upon myself to revise `lglicua`, my
shim/adaptor module that brings IM, CD, IUP (and PDFLIB7 and
FTGL) to a wider set of systems than the originally-advertised
Ubuntu for source compilation.  In particular, I was
previously able to support Linux Mint, and Red Hat variants
such as CentOS 7 and Rocky Linux 9.

In the most recent release (lglicua-0.1-alpha6), MX21_ahs_x64
is supported. I also try to support new releases where possible,
while aiming to stay within fairly stable distros, and away
from the more bleeding-edge ones.

However, key components such as the GNU C toolchain and the
Linux Kernel keep being updated, and it's sometimes a bit of a
gamble to see if compatibility is maintained.  Even keeping a
test rig supplied with package updates as new and/or bugfix
releases are made can turn into a full-time job for a largeish
set of OS images.

----

I've found a defect in CD's tecmake.mak -- well, actually this
file is identical across all Tecgraf SourceForge projects.
The problem was highlighted by a confusing failure to compile
cdgdk.c, with the error "Unable to find <gdk/gdk.h>".  By
using Locate, I could see that the file was installed as part
of the gtk3 suite, and both MX21_ahs_x64 and MX_21.1_ahs_x64
distros had no trouble.

The problem is that MX21.3_ahs_x64 is the first distro that
I've come across, that uses the fairly new Linux Kernel 6.0.x.

The Tecgraf build system, including tecmake.mak, has to pick
between GTK2 and GTK3, with an implied rule that newer kernels
would use GTK3.  However, kernel version testing stopped at 5,
and so 6 caused the build system to choose the lesser GTK2.

The fix is to add kernel versions in the GTK3 test portion of
tecmake.mak.  This file is identical across all of CD/IM/IUP,
with PDFLIB7 and FTGL being pseudo-copies of CD.

The patch is:

------------------------- cut here ------------------------
Index: tecmake.mak
===================================================================
--- tecmake.mak	(revision 901)
+++ tecmake.mak	(working copy)
@@ -297,6 +297,12 @@

 ifdef GTK_DEFAULT
   ifndef USE_GTK2
+    ifneq ($(findstring Linux7, $(TEC_UNAME)), )
+      USE_GTK3 = Yes
+    endif
+    ifneq ($(findstring Linux6, $(TEC_UNAME)), )
+      USE_GTK3 = Yes
+    endif
     ifneq ($(findstring Linux5, $(TEC_UNAME)), )
       USE_GTK3 = Yes
     endif
------------------------- cut here ------------------------


Sadly, this does not completely cure the CD build under
MX21.3_ahs_x64 -- there is a problem with another file trying to
access <hb.h> -- presumably HarfBuzz.  I have run out of time to
track this down at present.

I would appreciate updates to the SourceForge tecmake.mak files
quickly, rather than trying to fudge things within lglicua.  This
can happen regardless of whether a full release is prepared, as
lglicua never uses the snapshot-release builds; it always uses
the latest SourceForge Subversion sources.

cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] Updated "parse-build.lua" warnings... for iup-r5947, gcc 12 (5/5)

[sur-behoffski <sur...@gr...>]

G'day,


Attached are the warnings for iup-r5947, under gcc 12.

--

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] Updated "parse-build.lua" warnings... for cd-r901, gcc 12 (4/5)

[sur-behoffski <sur...@gr...>]

G'day,


Attached are the warnings for cd-r901, under gcc 12.

--

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] Updated "parse-build.lua" warnings... for pdflib7-r901, gcc 12 (3/5)

[sur-behoffski <sur...@gr...>]

G'day,


Attached are the warnings for pdflib7-r901, under gcc 12.

--

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] Updated "parse-build.lua" warnings... for ftgl-r901, gcc 12 (2/5)

[sur-behoffski <sur...@gr...>]

G'day,


Attached are the warnings for ftgl-r901, under gcc 12.

--

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] Updated "parse-build.lua" warnings... for IM-r820, gcc 12 (1/5)

[sur-behoffski <sur...@gr...>]

G'day,

Antonio mentioned he was hoping to release an updated set
of packages for the Tecgraf scientific/technical tools --
particularly IUP.

I've decided to work on preparing "lglicua-0.1-alpha7"
release to go on SourceForge, that picks up the latest tools
such as Lua 5.4.4 and LuaRocks 3.9.1, as well as expanding
the GNU/Linux platforms that it handles (including kernel
6.x,y, and both gcc-11.x and gcc-12.x).

When I looked at the diagnostic output, I noticed
significant duplication, due to a few header files that
contained warnings, being #included by multiple C/C++
sources.

So, I've reworked the script to remove duplicates.  The
result is that some report summaries are less than half
their former size.

---------

Attached are the warnings for IM-r820, under gcc 12.

(Others will follow: pdflib7, ftgl, cd, iup.)

--

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

[Iup-users] A couple of questions about the Gridbox control

[<col...@co...> <Col...@co...>]

1.	Is there a technique by which I can freeze (say) the leftmost two
columns in a wide Gridbox when scrolling across it?  I know that I can do it
using a MatrixEx control, but I need the cells in my grid to hold more than
just alphanumeric data but also lists, toggles and possibly other controls.
One avenue I will explore is having two gridboxes side to side, the
rightmost one in a scrollable container, but what other possibilities exist?

 

2.	Same gridbox... I need the ability to reorder rows at the users
request (a move-up/move-down facility to move one row at a time).  Emptying
and repopulating the gridbox is one option - what better ones exist?

 

 

Using Lua and IUP 3.28

[Iup-users] IUP binaries for Lua 5.3.6

[Milind G. <mil...@gm...>]

Hello,
        Was there any release for the IUP binaries for Lua 5.3.6 for
Windows 64 bit?

Thanks,
Milind

Re: [Iup-users] IupFrame too short when its title is wider than its content

[Ranier F. <ran...@ho...>]

>De: Stéphane Goujet <ste...@wa...>
>Enviado: segunda-feira, 19 de dezembro de 2022 10:16
>Para: iup...@li...
>Assunto: Re: [Iup-users] IupFrame too short when its title is wider than its content

>Hello,

>Le Sun, 18 Dec 2022 20:41:56 +0000,
>Ranier Fonseca <ran...@ho...> a écrit :

>> >  IupFrame doesn't take the width of the title into account when it
>> >calculates the width of the frame.
>> >  Therefore, when the content of the Frame is not wide, the title is
>> >cut short.
>> I didn't check if it's a bug or not.

  > Well, I guess that when we set a title, we expect it to be displayed
>fully and correctly, don't we? :-)
Not necessarily in all cases.
If the size is hardcoded, the title will probably be cut off.

>> But You can use IupVbox and IupHbox to change your layout and get the
>> result you need.

  >Yeah, thank you, but that's more like a work around, because you need
>to hardcode the dimension of the content, or calculate it by yourself
>(and the calculation will probably be at least as brittle as my Q&D
>patch).
Yes, my example was not entirely illuminating.
The point is that IupVbox and IupHbox allow you to create dynamic layouts.

regards,
Ranier Vilela

Re: [Iup-users] IupFrame too short when its title is wider than its content

[Stéphane G. <ste...@wa...>]

Hello,

Le Sun, 18 Dec 2022 20:41:56 +0000,
Ranier Fonseca <ran...@ho...> a écrit :

> >  IupFrame doesn't take the width of the title into account when it
> >calculates the width of the frame.
> >  Therefore, when the content of the Frame is not wide, the title is
> >cut short.  
> I didn't check if it's a bug or not.

   Well, I guess that when we set a title, we expect it to be displayed
fully and correctly, don't we? :-)


> But You can use IupVbox and IupHbox to change your layout and get the
> result you need.

  Yeah, thank you, but that's more like a work around, because you need
to hardcode the dimension of the content, or calculate it by yourself
(and the calculation will probably be at least as brittle as my Q&D
patch).

----

>>   My patch is just meant as an example (and a quick&dirty fix for
>> me), not for direct inclusion. It is probably very brittle: I didn't
>> account for the "_IUPFRAME_HAS_TITLE" I can see in other parts, I
>> assumed the result of iupdrvFontGetStringWidth() was reliable (is
>> it?), and I added an hardcoded value to get some extra space).

  BTW, I forgot to add to my list of assumptions: I also assumed that
the font and font size of the Label were the same as the default font,
which may be true or not, depending on which back-end is used.


Goodbye,
  Stéphane.

Re: [Iup-users] IupFrame too short when its title is wider than its content

[Ranier F. <ran...@ho...>]

>De: Stéphane Goujet <ste...@wa...>
>Enviado: domingo, 18 de dezembro de 2022 20:05
>Para: iup...@li...
>Assunto: [Iup-users] IupFrame too short when its title is wider than its content

>[I am using IUP version 3.30, with GTK2 on X11]

>Hello,
Hi Stéphane.

>  IupFrame doesn't take the width of the title into account when it
>calculates the width of the frame.
>  Therefore, when the content of the Frame is not wide, the title is
>cut short.

I didn't check if it's a bug or not.
But You can use IupVbox and IupHbox to change your layout and get the result you need.

#include <stddef.h>
#include <iup.h>

int main(void) {
  Ihandle *dlg, *frame, *button;
  Ihandle *hbox;
  Ihandle *vbox;

  IupOpen(NULL, NULL);

  button = IupButton("Button", NULL);

  hbox = IupHbox(button, NULL);
  IupSetAttribute(hbox, "SIZE", "200x80");

  frame = IupFrame(hbox);
  IupSetAttribute(frame, "TITLE", "A title wider than the button");

  vbox = IupVbox(frame, NULL);
  dlg = IupDialog(vbox);
  IupSetAttribute(dlg, "TITLE", "Test bug length of frame when title is set");
  IupSetAttribute(dlg, "SIZE", "200x80");

  IupShowXY(dlg, IUP_CENTER, IUP_CENTER);
  IupMainLoop();
  IupClose();

  return 0;
}

regards,
Ranier Vilela

[Iup-users] IupFrame too short when its title is wider than its content

[Stéphane G. <ste...@wa...>]

[I am using IUP version 3.30, with GTK2 on X11]

Hello,

  IupFrame doesn't take the width of the title into account when it
calculates the width of the frame.
  Therefore, when the content of the Frame is not wide, the title is
cut short.


   Here is a very simple example :
--------------------------
#include <stddef.h>
#include <iup.h>

int main(void) {
  Ihandle *dlg, *frame, *button;
	
  IupOpen(NULL, NULL);
	
  button = IupButton("Button", NULL);
	
  frame = IupFrame(button);
  IupSetAttribute(frame, "TITLE", "A title wider than the button");
  
  dlg = IupDialog(frame);
  IupSetAttribute(dlg, "TITLE", "Test bug length of frame when title is set");
  IupSetAttribute(dlg, "SIZE", "200x80");

  IupShowXY(dlg, IUP_CENTER, IUP_CENTER);
  IupMainLoop();
  IupClose();
	
  return 0;	
}
--------------------------

  I don't know if this mailing list allows it, but I attach 2
screenshots, one with the problem, and one after some patching.


  My patch is just meant as an example (and a quick&dirty fix for me),
not for direct inclusion. It is probably very brittle: I didn't account
for the "_IUPFRAME_HAS_TITLE" I can see in other parts, I assumed the
result of iupdrvFontGetStringWidth() was reliable (is it?), and I added
an hardcoded value to get some extra space).

  It is short, it simply calculates a minimal width for the frame based
on the width of the title string; and if the existing calculation is
smaller than that, it uses that minimal width instead.

  Here it is anyway:

--------------------------
--- iup.orig/src/iup_frame.c	2019-07-25 21:55:01.000000000 +0200
+++ iup/src/iup_frame.c	2022-12-18 20:23:34.404853218 +0100
@@ -30,6 +30,15 @@
   return height;
 }
 
+int iupFrameGetTitleWidth(Ihandle* ih)
+{
+  char *title = iupAttribGet(ih, "TITLE");
+  
+  if (!title) return 0;
+  
+  return iupdrvFontGetStringWidth(ih, title);
+}
+
 static void iFrameGetDecorSize(Ihandle* ih, int *width, int *height)
 {
   if (iupdrvFrameGetDecorSize(ih, width, height))
@@ -98,6 +107,7 @@
 static void iFrameComputeNaturalSizeMethod(Ihandle* ih, int *w, int *h, int *children_expand)
 {
   int decorwidth, decorheight;
+  int min_width;
   Ihandle* child = ih->firstchild;
 
   iFrameGetDecorSize(ih, &decorwidth, &decorheight);
@@ -113,6 +123,10 @@
     *w += child->naturalwidth;
     *h += child->naturalheight;
   }
+  
+  min_width = decorwidth + iupFrameGetTitleWidth(ih) + 7; // 7 = some margin
+  
+  if (*w < min_width) *w = min_width;
 }
 
 static void iFrameSetChildrenCurrentSizeMethod(Ihandle* ih, int shrink)
--------------------------

Goodbye,
  Stéphane.

Re: [Iup-users] Reminder about IUP fixes and improvements since 3.30 (was: Win installer for IUP 3.30)

[Ranier F. <ran...@ho...>]

>De: Antonio Scuri <ant...@gm...>
>Enviado: quinta-feira, 8 de dezembro de 2022 11:34

>  Yes, It's about time. I'm planning to release a new version in January after the holidays.
Good news.

If there is interest in including in the release, I have some patches.
The first, attached, refers to arrays that can be declared with static const * const, doing rodata,
which improves performance when accessing them.

It also contains minor bugfixes.

compiled with msvc 2019 32bits.

Are you interested in changing some function parameters that can safely be const?

regards,
Ranier Vilela

[Iup-users] New release follow-up: IM and CD Subversion details...

[sur-behoffski <sur...@gr...>]

G'day scuri,

Nice to hear that a new release of IUP is being contemplated.

For completeness, here's a similar treatment for:

     - IM (3.15, estimated r816, now at r820); and
     - CD (5.14, estimated r894, now at r901).

For both packages, it's over two years since a major release
occurred.

You might like to update copyright year to 2023 as part of a
post-new-year release of these packages.

As always, thank you for your efforts.

cheers,

s-b etc etc

---------------- cut here ----------------


IM:

* July 2020:
    r810 | 27 19:41 | Undo - Removed suffix "6" from Freetype libraries in Windows 
    r811 | 28 12:28 | 
    r812 | 29 21:14 | 
    r813 | 30 23:40 | Preparing version 3.15
    r814 | 30 23:59 | 
    r816 | 31 11:42 | 

* September 2020:
    r817 | 10 18:59 | Fixed: imImageSetAlpha when image data type is different than BYTE.

* October 2020:
    r818 | 10 17:49 | Fix in documentation for ProcessRotate90

* December 2020:
    r819 |  7 13:18 | comment

* January 2021:
    r820 |  8 16:22 | Default VS debug project to Lua 5.4



---------------- cut here ----------------



CD:


* July 2020:
    r888 | 27 20:04 | Removed PDFLib code from inside CD source folder. It is now in a separated SVN folder.
    r889 | 29 21:14 | 
    r890 | 30 23:42 | Preparing version 5.14
    r894 | 31 11:42 | 

* August 2020:
    r895 |  3 22:16 | 

* January 2021:
    r897 |  8 16:22 | Default VS debug project to Lua 5.4

* September 2021:
    r898 |  5 17:14 | Fix for GCC 10.3 warning (buffer overflow, undefined behaviour) in cd/src/cd_text.c (cd-r897)
    r899 | 11 18:21 | Another cd-r898 "-Wformat-overflow" patch: cd/src/cd_vectortext.c

* December 2021:
    r900 | 12 02:03 | fix linker

* March 2022:
    r901 |  3 01:40 | SourceForge Badges



---------------- (End of CD SVN log summary.) ----------------

Re: [Iup-users] Reminder about IUP fixes and improvements since 3.30 (was: Win installer for IUP 3.30)

[Antonio S. <ant...@gm...>]

  Thanks,

  Yes, It's about time. I'm planning to release a new version in January
after the holidays.

Best,
Scuri


Em qua., 7 de dez. de 2022 às 22:58, sur-behoffski <
sur...@gr...> escreveu:

> G'day,
>
> Just a reminder that IUP 3.30, the latest package, was released in
> approximately early
> August 2020.  There have been quite a lot of changes, including both bug
> fixes and new
> facilities, since that time.  These are listed in the project's
> SourceForge (SF)
> Subversion (SVN) repository.
>
> I estimate that 3.30 was based on SVN revision r5892, 2 August 2020 --
> over two tears
> ago.
>
> Here is a summary of SVN changes from r5880 (July 2020) to r5947 (latest,
> November 2022).
> I've used "svn log" and a quick Lua script to create this summary.
>
> (As always, one of the main drivers of my SF "lglicua" project is to have
> the SVN
> repositories for IM, CD and IUP as my base, as the last package releases
> were quite old
> and had cruft (C compiler warnings) and/or bugs.)
>
> cheers,
> sur-behoffski (Brenton Hoff)
> programmer, Grouse Software
>
> ---------------- cut here ----------------
>
> * July 2020:
>     r5880 | 27 13:18 | Changed do Minimum Windows 7
>     r5881 | 27 19:42 | Undo - Removed suffix "6" from Freetype libraries
> in Windows
>     r5882 | 29 18:30 | New: EXTRATEXTid and EXTRATEXTWIDTH attributes for
> IupFlatTree. Thanks to M. Voznesenskiy.
>     r5883 | 29 21:14 |
>     r5884 | 30 16:45 | Fixed extra text area resize when clicked after the
> last node
>     r5885 | 30 23:40 | Preparing version 3.30
>     r5886 | 30 23:59 |
>     r5887 | 31 11:41 |
>     r5888 | 31 13:59 |
>     r5889 | 31 18:28 |
>     r5890 | 31 18:28 | 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.
>
> * August 2020:
>     r5891 |  1 00:42 |
>     r5892 |  2 15:32 |
>     r5893 | 10 13:34 | removed unused function
>     r5894 | 17 12:19 | Added missing "int len" in IupDrawGetTextSize
> documentation
>     r5895 | 17 13:00 | added dependencies comments
>     r5896 | 24 12:45 | Added flattree
>     r5897 | 24 14:24 | small improvements
>     r5898 | 24 17:14 | Fixed: key mapping for = virtual key in Windows
> when + is in the same key.
>     r5899 | 24 17:15 |
>     r5900 | 31 13:15 |
>
> * September 2020:
>     r5901 |  4 18:05 | Added missing dll16 stub support
>     r5902 |  9 22:27 |
>     r5903 | 10 18:52 | Isolated test for valid characters to enter edition
> mode
>     r5904 | 13 17:40 | Fixed documentation
>     r5905 | 18 21:35 | Clean up usage of attribute registration flags,
> specially for DEFAULT and NOT_MAPPED.
>     r5906 | 20 18:59 | Fixed: VALUE attribute for IupFlatButton when
> TOGGLE=Yes and IupFlatToggle.
>     r5907 | 27 21:41 | Fixed: VALUE attribute for IupFlatButton when
> TOGGLE=Yes and IupFlatToggle.
>
> * October 2020:
>     r5908 |  4 13:53 | Fixed typos
>     r5909 |  4 15:08 | New: EXTRABOXid attribute for the IupFlatTabs.
>     r5910 |  6 00:05 | Fixed EXTRABOX indexing
>
> * November 2020:
>     r5911 | 29 19:56 | New: SELECTED attribute for IupFlatButton.
>
> * December 2020:
>     r5912 |  7 12:53 | STEP default for real parameters is now
> (max-min)/100
>     r5913 | 12 18:13 | Fixed: VALUECHANGING_CB callback not called when
> value was changed using the keyboard in IupFlatVal.
>
> * January 2021:
>     r5914 |  1 17:26 | Fixed: MOUSEBUTTON global attribute when 'W' is
> used in button with a state=-1 in Windows.
>     r5915 |  1 17:39 | Remove unused flag
>     r5916 |  1 19:46 | Changed: iuplua_close will now destroy all dialogs
> and all elements that have names that where created with the same Lua
> context.
>     r5917 |  2 14:17 | Fixing imProcessRenderFloodFill parameters
>     r5918 |  2 14:53 | Fix on iuplua_close
>     r5919 |  3 15:27 | Fixed title
>     r5920 |  3 18:58 | Small ORIGIN optimization
>     r5921 |  5 11:41 | Workaround for lua states created with lua_newthread
>     r5922 |  5 14:51 | Improving ldestroy_cb
>     r5923 |  6 20:37 | Using the main thread for the IupLua callbacks
>     r5924 |  6 20:40 | Using the main thread for the IupLua callbacks
>     r5925 |  7 14:16 | Changed: behavior of LDESTROY_CB callback to be
> called after the element was detached and unmapped.
>     r5926 | 13 22:14 | comments
>     r5927 | 13 22:16 | Fixed: support for IupDatePick, IupCalendar and
> IupThread in LEDC application.
>     r5928 | 13 22:17 | Default VS debug project to Lua 5.4
>
> * June 2021:
>     r5929 | 27 23:08 | Fixed: IupSetClassDefaultAttribute function. Thanks
> to D. Cravey.
>
> * October 2021:
>     r5930 | 12 19:10 | ignore list
>
> * December 2021:
>     r5931 | 12 02:05 | Add other tests in samples
>     r5932 | 12 02:27 | fix typos
>     r5933 | 12 02:28 | Better highlight processing in drawn elements
>     r5934 | 12 02:33 | New TOUCHREADY global attribute
>     r5935 | 12 02:33 | New GESTURE canvas attribute
>     r5936 | 12 02:34 | added some checks
>
> * February 2022:
>     r5937 | 26 13:18 | Fix on FORMATDATASTRING
>     r5938 | 27 13:39 | Exporting iupwinPostMessageFilter
>     r5939 | 27 17:32 | spelling
>     r5940 | 28 12:52 | missing DLL export of iupwinPostMessageFilter
>     r5941 | 28 13:12 | Fix on internal SDK documentation
>
> * March 2022:
>     r5942 |  3 01:40 | SourceForge Badges
>
> * August 2022:
>     r5943 | 23 21:40 | New: SCROLLVISIBLE attribute for IupList, IupTree,
> IupText and IupCanvas, in Windows.
>
> * November 2022:
>     r5944 |  3 17:15 | Added missing define in the declaration
>     r5945 |  3 17:50 | Fixed: IupFlatToggle initialization when inside a
> IupRadio.
>     r5946 | 10 11:37 | Fixed: IupToggle initialization when inside a
> IupRadio.
>     r5947 | 16 11:35 | Missing userdata in IupPostMessage on Motif (thanks
> to M. Nikolic)
>
>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

[Iup-users] Reminder about IUP fixes and improvements since 3.30 (was: Win installer for IUP 3.30)

[sur-behoffski <sur...@gr...>]

G'day,

Just a reminder that IUP 3.30, the latest package, was released in approximately early
August 2020.  There have been quite a lot of changes, including both bug fixes and new
facilities, since that time.  These are listed in the project's SourceForge (SF)
Subversion (SVN) repository.

I estimate that 3.30 was based on SVN revision r5892, 2 August 2020 -- over two tears
ago.

Here is a summary of SVN changes from r5880 (July 2020) to r5947 (latest, November 2022).
I've used "svn log" and a quick Lua script to create this summary.

(As always, one of the main drivers of my SF "lglicua" project is to have the SVN
repositories for IM, CD and IUP as my base, as the last package releases were quite old
and had cruft (C compiler warnings) and/or bugs.)

cheers,
sur-behoffski (Brenton Hoff)
programmer, Grouse Software

---------------- cut here ----------------

* July 2020:
    r5880 | 27 13:18 | Changed do Minimum Windows 7
    r5881 | 27 19:42 | Undo - Removed suffix "6" from Freetype libraries in Windows 
    r5882 | 29 18:30 | New: EXTRATEXTid and EXTRATEXTWIDTH attributes for IupFlatTree. Thanks to M. Voznesenskiy.
    r5883 | 29 21:14 | 
    r5884 | 30 16:45 | Fixed extra text area resize when clicked after the last node
    r5885 | 30 23:40 | Preparing version 3.30
    r5886 | 30 23:59 | 
    r5887 | 31 11:41 | 
    r5888 | 31 13:59 | 
    r5889 | 31 18:28 | 
    r5890 | 31 18:28 | 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.

* August 2020:
    r5891 |  1 00:42 | 
    r5892 |  2 15:32 | 
    r5893 | 10 13:34 | removed unused function
    r5894 | 17 12:19 | Added missing "int len" in IupDrawGetTextSize documentation
    r5895 | 17 13:00 | added dependencies comments
    r5896 | 24 12:45 | Added flattree
    r5897 | 24 14:24 | small improvements
    r5898 | 24 17:14 | Fixed: key mapping for = virtual key in Windows when + is in the same key.
    r5899 | 24 17:15 | 
    r5900 | 31 13:15 | 

* September 2020:
    r5901 |  4 18:05 | Added missing dll16 stub support
    r5902 |  9 22:27 | 
    r5903 | 10 18:52 | Isolated test for valid characters to enter edition mode
    r5904 | 13 17:40 | Fixed documentation
    r5905 | 18 21:35 | Clean up usage of attribute registration flags, specially for DEFAULT and NOT_MAPPED.
    r5906 | 20 18:59 | Fixed: VALUE attribute for IupFlatButton when TOGGLE=Yes and IupFlatToggle.
    r5907 | 27 21:41 | Fixed: VALUE attribute for IupFlatButton when TOGGLE=Yes and IupFlatToggle.

* October 2020:
    r5908 |  4 13:53 | Fixed typos
    r5909 |  4 15:08 | New: EXTRABOXid attribute for the IupFlatTabs.
    r5910 |  6 00:05 | Fixed EXTRABOX indexing

* November 2020:
    r5911 | 29 19:56 | New: SELECTED attribute for IupFlatButton.

* December 2020:
    r5912 |  7 12:53 | STEP default for real parameters is now (max-min)/100
    r5913 | 12 18:13 | Fixed: VALUECHANGING_CB callback not called when value was changed using the keyboard in IupFlatVal.

* January 2021:
    r5914 |  1 17:26 | Fixed: MOUSEBUTTON global attribute when 'W' is used in button with a state=-1 in Windows.
    r5915 |  1 17:39 | Remove unused flag
    r5916 |  1 19:46 | Changed: iuplua_close will now destroy all dialogs and all elements that have names that where created with the same Lua context.
    r5917 |  2 14:17 | Fixing imProcessRenderFloodFill parameters
    r5918 |  2 14:53 | Fix on iuplua_close
    r5919 |  3 15:27 | Fixed title
    r5920 |  3 18:58 | Small ORIGIN optimization
    r5921 |  5 11:41 | Workaround for lua states created with lua_newthread
    r5922 |  5 14:51 | Improving ldestroy_cb
    r5923 |  6 20:37 | Using the main thread for the IupLua callbacks
    r5924 |  6 20:40 | Using the main thread for the IupLua callbacks
    r5925 |  7 14:16 | Changed: behavior of LDESTROY_CB callback to be called after the element was detached and unmapped. 
    r5926 | 13 22:14 | comments
    r5927 | 13 22:16 | Fixed: support for IupDatePick, IupCalendar and IupThread in LEDC application.
    r5928 | 13 22:17 | Default VS debug project to Lua 5.4

* June 2021:
    r5929 | 27 23:08 | Fixed: IupSetClassDefaultAttribute function. Thanks to D. Cravey.

* October 2021:
    r5930 | 12 19:10 | ignore list

* December 2021:
    r5931 | 12 02:05 | Add other tests in samples
    r5932 | 12 02:27 | fix typos
    r5933 | 12 02:28 | Better highlight processing in drawn elements
    r5934 | 12 02:33 | New TOUCHREADY global attribute
    r5935 | 12 02:33 | New GESTURE canvas attribute
    r5936 | 12 02:34 | added some checks

* February 2022:
    r5937 | 26 13:18 | Fix on FORMATDATASTRING
    r5938 | 27 13:39 | Exporting iupwinPostMessageFilter
    r5939 | 27 17:32 | spelling
    r5940 | 28 12:52 | missing DLL export of iupwinPostMessageFilter
    r5941 | 28 13:12 | Fix on internal SDK documentation

* March 2022:
    r5942 |  3 01:40 | SourceForge Badges

* August 2022:
    r5943 | 23 21:40 | New: SCROLLVISIBLE attribute for IupList, IupTree, IupText and IupCanvas, in Windows.

* November 2022:
    r5944 |  3 17:15 | Added missing define in the declaration
    r5945 |  3 17:50 | Fixed: IupFlatToggle initialization when inside a IupRadio.
    r5946 | 10 11:37 | Fixed: IupToggle initialization when inside a IupRadio.
    r5947 | 16 11:35 | Missing userdata in IupPostMessage on Motif (thanks to M. Nikolic)

Re: [Iup-users] Windows installer for Iup

[<su...@sc...>]

Wow!

Thanks for the contribution.

On 2022-12-04 06:56, Jesús Ruiz wrote:
> Hi,
> 
> I have just pushed a repo to github that creates a Windows
> installer for Iup.
> 
> See https://github.com/jesrui/iup-installer
> 
> There is also a release:
> 
> https://github.com/jesrui/iup-installer/releases
> 
> From the README:
> 
>     This repo contains scripts to download Iup 3.30 and its 
> dependencies
>     from sourceforge and create a Windows installer for the downloaded
>     files.
> 
>     The installer includes static libs and dlls compiled for win32 x64 
> with
>     vs16, headers, Lua 5.4 bindings, examples and documentation.
> 
> Cheers!
> 
> JR
> 
> 
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users

[Iup-users] Windows installer for Iup

[Jesús R. <je...@po...>]

Hi,

I have just pushed a repo to github that creates a Windows
installer for Iup.

See https://github.com/jesrui/iup-installer

There is also a release:

https://github.com/jesrui/iup-installer/releases

>From the README:

    This repo contains scripts to download Iup 3.30 and its dependencies
    from sourceforge and create a Windows installer for the downloaded
    files.

    The installer includes static libs and dlls compiled for win32 x64 with
    vs16, headers, Lua 5.4 bindings, examples and documentation.

Cheers!

JR

Re: [Iup-users] IupConfig

[Andrew R. <aro...@co...>]

Sorry for the typo. The Actual width for the MiscList doesn't matter. 669 and
699 both create the same width dialog.


On 12/2/2022 at 4:17 PM, Andrew Robinson <aro...@co...> wrote:


PPS -- In a related issue the following text:




[MiscList]
Height=404
Maximized=0
Width=699
X=0
Y=639




[PolymerDB]
Height=645
Maximized=0
Width=670
X=0
Y=0





In a config file produces the following result:









The bottom dialog is not the same width as the upper dialog (the bottom dialog
is 17 pixels shorter). This screen capture also shows the problem with the
offset setting/readings. I wanted to set all dialogs to the same width and
starting position using the config file for the user.




On 11/29/2022 at 5:35 PM, Andrew Robinson <aro...@co...> wrote:


PS -- I thought it may or may not be relevant but I am using a monitor with
2560x1600 resolution.


On 11/28/2022 at 5:54 AM, Andrew Robinson <aro...@co...> wrote:


They are placed at the top manually. I also manually edited the config file
and set X=0, which causes the dialogs to appear 8 pixels from the left edge of
the screen (or 2 pixels when the dialog has no min/max buttons).


On 11/28/2022 at 4:48 AM, Antonio Scuri <ant...@gm...> wrote:


 Are those dialogs maximized or placed at the top manually?



Em dom., 27 de nov. de 2022 às 21:10, Andrew Robinson <aro...@co...>
escreveu:




I measured the offset when all dialogs were set to X=0. The dialogs that have
RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels whereas
the don't have those parameters set have an offset of 8 pixels, so apparently
whatever is rendered in the titlebar of the dialog can affect its X,Y offset.




Hope that helps.




Signed,

Andres


On 11/27/2022 at 8:19 AM, Andrew Robinson <aro...@co...> wrote:


Ola again,




When I place a dialog at the leftmost topmost corner of the Windows OS and
close the dialog, upon reinitialization the dialog will not appear where I
placed it but displaced by about 7 pixels. When I look at the config file that
was created by Iup, I am seeing:




[PolymerDB]
Height=646
Maximized=0
Width=670
X=-7
Y=0




X should equal 0 but is unable to do that, therefore no Iup dialogs can be
placed on the leftside of the main Windows OS.




Signed,

Andres




╔═══════════════╗
║  Environment  ║
╟───────────────╢
║ IUP   v3.30   ║
║ IM    v3.12   ║
║ CD    v5.11.1 ║
║ Win10 v21H1   ║
╚═══════════════╝



_______________________________________________
Iup-users mailing list
Iup...@li...
https://lists.sourceforge.net/lists/listinfo/iup-users

Re: [Iup-users] IupConfig

[Andrew R. <aro...@co...>]

PPS -- In a related issue the following text:




[MiscList]
Height=404
Maximized=0
Width=699
X=0
Y=639




[PolymerDB]
Height=645
Maximized=0
Width=670
X=0
Y=0





In a config file produces the following result:









The bottom dialog is not the same width as the upper dialog (the bottom dialog
is 17 pixels shorter). This screen capture also shows the problem with the
offset setting/readings. I wanted to set all dialogs to the same width and
starting position using the config file for the user.




On 11/29/2022 at 5:35 PM, Andrew Robinson <aro...@co...> wrote:


PS -- I thought it may or may not be relevant but I am using a monitor with
2560x1600 resolution.


On 11/28/2022 at 5:54 AM, Andrew Robinson <aro...@co...> wrote:


They are placed at the top manually. I also manually edited the config file
and set X=0, which causes the dialogs to appear 8 pixels from the left edge of
the screen (or 2 pixels when the dialog has no min/max buttons).


On 11/28/2022 at 4:48 AM, Antonio Scuri <ant...@gm...> wrote:


 Are those dialogs maximized or placed at the top manually?



Em dom., 27 de nov. de 2022 às 21:10, Andrew Robinson <aro...@co...>
escreveu:




I measured the offset when all dialogs were set to X=0. The dialogs that have
RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels whereas
the don't have those parameters set have an offset of 8 pixels, so apparently
whatever is rendered in the titlebar of the dialog can affect its X,Y offset.




Hope that helps.




Signed,

Andres


On 11/27/2022 at 8:19 AM, Andrew Robinson <aro...@co...> wrote:


Ola again,




When I place a dialog at the leftmost topmost corner of the Windows OS and
close the dialog, upon reinitialization the dialog will not appear where I
placed it but displaced by about 7 pixels. When I look at the config file that
was created by Iup, I am seeing:




[PolymerDB]
Height=646
Maximized=0
Width=670
X=-7
Y=0




X should equal 0 but is unable to do that, therefore no Iup dialogs can be
placed on the leftside of the main Windows OS.




Signed,

Andres




╔═══════════════╗
║  Environment  ║
╟───────────────╢
║ IUP   v3.30   ║
║ IM    v3.12   ║
║ CD    v5.11.1 ║
║ Win10 v21H1   ║
╚═══════════════╝



_______________________________________________
Iup-users mailing list
Iup...@li...
https://lists.sourceforge.net/lists/listinfo/iup-users

Re: [Iup-users] IupConfig

[Andrew R. <aro...@co...>]

PS -- I thought it may or may not be relevant but I am using a monitor with
2560x1600 resolution.


On 11/28/2022 at 5:54 AM, Andrew Robinson <aro...@co...> wrote:


They are placed at the top manually. I also manually edited the config file
and set X=0, which causes the dialogs to appear 8 pixels from the left edge of
the screen (or 2 pixels when the dialog has no min/max buttons).


On 11/28/2022 at 4:48 AM, Antonio Scuri <ant...@gm...> wrote:


 Are those dialogs maximized or placed at the top manually?



Em dom., 27 de nov. de 2022 às 21:10, Andrew Robinson <aro...@co...>
escreveu:




I measured the offset when all dialogs were set to X=0. The dialogs that have
RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels whereas
the don't have those parameters set have an offset of 8 pixels, so apparently
whatever is rendered in the titlebar of the dialog can affect its X,Y offset.




Hope that helps.




Signed,

Andres


On 11/27/2022 at 8:19 AM, Andrew Robinson <aro...@co...> wrote:


Ola again,




When I place a dialog at the leftmost topmost corner of the Windows OS and
close the dialog, upon reinitialization the dialog will not appear where I
placed it but displaced by about 7 pixels. When I look at the config file that
was created by Iup, I am seeing:




[PolymerDB]
Height=646
Maximized=0
Width=670
X=-7
Y=0




X should equal 0 but is unable to do that, therefore no Iup dialogs can be
placed on the leftside of the main Windows OS.




Signed,

Andres




╔═══════════════╗
║  Environment  ║
╟───────────────╢
║ IUP   v3.30   ║
║ IM    v3.12   ║
║ CD    v5.11.1 ║
║ Win10 v21H1   ║
╚═══════════════╝



_______________________________________________
Iup-users mailing list
Iup...@li...
https://lists.sourceforge.net/lists/listinfo/iup-users

Re: [Iup-users] IupConfig

[Andrew R. <aro...@co...>]

They are placed at the top manually. I also manually edited the config file
and set X=0, which causes the dialogs to appear 8 pixels from the left edge of
the screen (or 2 pixels when the dialog has no min/max buttons).


On 11/28/2022 at 4:48 AM, Antonio Scuri <ant...@gm...> wrote:


 Are those dialogs maximized or placed at the top manually?



Em dom., 27 de nov. de 2022 às 21:10, Andrew Robinson <aro...@co...>
escreveu:




I measured the offset when all dialogs were set to X=0. The dialogs that have
RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels whereas
the don't have those parameters set have an offset of 8 pixels, so apparently
whatever is rendered in the titlebar of the dialog can affect its X,Y offset.




Hope that helps.




Signed,

Andres


On 11/27/2022 at 8:19 AM, Andrew Robinson <aro...@co...> wrote:


Ola again,




When I place a dialog at the leftmost topmost corner of the Windows OS and
close the dialog, upon reinitialization the dialog will not appear where I
placed it but displaced by about 7 pixels. When I look at the config file that
was created by Iup, I am seeing:




[PolymerDB]
Height=646
Maximized=0
Width=670
X=-7
Y=0




X should equal 0 but is unable to do that, therefore no Iup dialogs can be
placed on the leftside of the main Windows OS.




Signed,

Andres




╔═══════════════╗
║  Environment  ║
╟───────────────╢
║ IUP   v3.30   ║
║ IM    v3.12   ║
║ CD    v5.11.1 ║
║ Win10 v21H1   ║
╚═══════════════╝



_______________________________________________
Iup-users mailing list
Iup...@li...
https://lists.sourceforge.net/lists/listinfo/iup-users

Re: [Iup-users] IupConfig

[Antonio S. <ant...@gm...>]

 Are those dialogs maximized or placed at the top manually?

Em dom., 27 de nov. de 2022 às 21:10, Andrew Robinson <aro...@co...>
escreveu:

> I measured the offset when all dialogs were set to X=0. The dialogs that
> have RESIZE='NO', MAXBOX='NO', and MINBOX='NO' have an offset of +2 pixels
> whereas the don't have those parameters set have an offset of 8 pixels, so
> apparently whatever is rendered in the titlebar of the dialog can affect
> its X,Y offset.
>
> Hope that helps.
>
> Signed,
> Andres
>
> On 11/27/2022 at 8:19 AM, Andrew Robinson <aro...@co...> wrote:
>
> Ola again,
>
> When I place a dialog at the leftmost topmost corner of the Windows OS and
> close the dialog, upon reinitialization the dialog will not appear where I
> placed it but displaced by about 7 pixels. When I look at the config file
> that was created by Iup, I am seeing:
>
> [PolymerDB]
> Height=646
> Maximized=0
> Width=670
> X=-7
> Y=0
>
> X should equal 0 but is unable to do that, therefore no Iup dialogs can be
> placed on the leftside of the main Windows OS.
>
> Signed,
> Andres
>
> ╔═══════════════╗
> ║  Environment  ║
> ╟───────────────╢
> ║ IUP   v3.30   ║
> ║ IM    v3.12   ║
> ║ CD    v5.11.1 ║
> ║ Win10 v21H1   ║
> ╚═══════════════╝
>
>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>