Recent changes to support-requests

Default backcolor changed

2026-10-10T18:31:17.702000Z

Hi Wilfried,

It appears that there have been changes to the background color of various objects : white instead of gray. I don't really understand the usefulness of this change, but it poses many problems.

This requires using the BACKCOLOR parameter for quite a few objects:
OWNERBUTTON, SAY, WINDOW, DIALOG ...

Certainly, it is doable, but it requires a good amount of work which we would have done without, and there are at least two exceptions to these doable modifications.

Impossible to use BACKCOLOR with TAB, and therefore obligatory to use BACKCOLOR but with white, this time for SAY, ....

In Hwg_MsgGet() function, no way to do it.
Besides, I haven't explored all the functions, just the ones I use, but there may be others.

Will there be a possibility for these two cases to set BACKCOLOR?
And finally, will it be possible to go back to the old value?

Thank you
A+

#89 Curious crash

2026-09-17T06:44:33.840000Z

Hi Wilfried,

I finally found the cause of the segmentation fault.

I embed the images into the executable using hwmake for Linux with the hwg_cHex2Bin() function. Hwmake generates five files:

memvar.prg
public.prg
loadhex.prg
inithex.prg
objects.prg

These files are included in the main .prg file.

In the case of this crash, the source code happened to be in a different .prg file, and I had forgotten to include memvar.prg in that file.

Now that I have modified all the relevant lines :

changing cImageDir + "/blank.png" to oObj_Blank
there is no longer a crash.

However, I wanted to take it a step further and replace all references to cImageDir with the objects. While this works in the vast majority of cases, there is one specific instance where a strange crash occurs as soon as I touch the mouse, even though the mouse action seems completely unrelated.

Example:

     cimage=cImageDir+iif(rgv==1.and.rgh==1,"g","")+"blank.png"
     oImage="oObj_"+iif(rgv==1.and.rgh==1,"g","")+"blank"
//     cImage = "/usr/src/ClipWord3/images/gblank.png"
//     oImage = oObj_gblank

// ok >
     &(casecol):oBitmap := &(oImage):AddFile(cImage)

// Erreur de segmentation >
//   &(casecol):oBitmap := HBitmap(&(oImage))  >> Erreur de segmentation

//   overflow allocating >>
//   &(casecol):oBitmap := &(oImage) >>
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GdkPixbuf-CRITICAL  : gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
//     (ClipWord3:7413): GLib-ERROR  : /build/glib2.0-QZt2qP/glib2.0-2.48.2/./glib/gmem.c:328: overflow allocating 18446744073709551615*18446744073709551615 bytes
//     ./script : ligne 3 :  7413 Trappe pour point d'arrêt et de trace              ./ClipWord3

If you have any idea where the problem might be coming from...

Thanks.
A+

#89 Curious crash

2026-07-17T16:48:16.345000Z

Hello Alain,
with commit r3829 i have done
some more modifications,
but no crash appeared.

Can you modify the sample
to provocate the crash ?

With regards,
MNI TNX, 73 es 55 de
DF7BE, Wilfried

#89 Curious crash

2026-07-12T14:08:02.270000Z

Hi Wilfried,

No flat, no OF param, but crashes if more than one button is usinf image object.

A+

#92 UpDown values

2026-07-12T13:12:14.485000Z

Hi Wilfried;
The button 'Set Result' make the same as my button trick, except it doesn't close the dialog.

So, I don't understand the reason of this button, and trick, which ought to be named ok, is the way to bypass this problem.

But I think it's a bug of updown.prg, and I think that Alexander ought to be the person who can correct this problem, or explain us where we failed.

A+

#92 UpDown values

2026-07-03T07:45:03.565000Z

Hello Alain,
i modified your sample program for
safe run as Ticket92.prg in the test directory.
Please read the notes in the comment lines.
Also the command documentation is updated.

So respond, if this is OK for you.
In the next few days i will look
for next tickets.

Advice:
Your WWW http://jujuland.pagesperso-orange.fr
mentioned in the sample program is outdated.

MNI TNX, 73 es 55 de
DF7BE, Wilfried

#92 UpDown values

2026-07-02T08:02:24.877000Z

A new version with a temporary solution to the bug

A+

#92 UpDown values

2026-07-01T13:29:01.412000Z

Hi, here is a small test :

Button ok : will quit the dialog, and display oUpDown:value (=0) and cResult (=5) as initialized
Button Display : set correctly cResult, and then quitting, display 0 and the real value of cResult
Cancel : quit

It seems tha value() is lost when quitting the dialog.

Except using a solution display, what I dont wan't to use, I have for now no solution.

Thanks
A+

#92 UpDown values

2026-06-30T13:34:42.167000Z

Hello Alain
Please post a little sample program.
There is no description in the HWGUI
commands docu, i will add this
in case of looking for this ticket.

In the next few days, i will look for
some more tickets.

MNI TNX, 73 es 55 de
Wilfried, DF7BE

UpDown values

2026-06-28T11:41:28.288000Z

Hi,
I tried to use this object, and I failed ...

@ 555,149 UPDOWN oUpDown INIT 5 RANGE 1, 10 SIZE 45, 22
...
nUpDown=oUpDown:value()

When I want to get the value, it always return 0

Where do I failed ?
Thanks
A+