windom-users Mailing List for WinDom, a high level GEM library.

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Attached is a patch (diff -u) to fix the font selector crash in TOS 1.04 and 
earlier, as described in a previous email.

Roger Burrows

Yes, of course !
Le 13 oct. 2011 07:10, "Roger Burrows" <rfb...@ym...> a écrit :

> Windom crashes in the font selector on TOS 1.04 and earlier, due to the
> small
> supervisor stack in those versions of TOS.  Claude Labelle reported this a
> while ago on SF.  I have a simple patch that fixes this (though it's not
> thread
> safe since it uses a static area).  Should I post it here?
>
> Roger Burrows
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Windom-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/windom-users
>

Windom crashes in the font selector on TOS 1.04 and earlier, due to the small 
supervisor stack in those versions of TOS.  Claude Labelle reported this a 
while ago on SF.  I have a simple patch that fixes this (though it's not thread 
safe since it uses a static area).  Should I post it here?

Roger Burrows

Bugs item #3404565, was opened at 2011-09-05 20:04
Message generated for change (Tracker Item Submitted) made by perdrix11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=521411&aid=3404565&group_id=68507

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Claude Labelle (perdrix11)
Assigned to: Nobody/Anonymous (nobody)
Summary: FontSel() crash on TOS 1.04

Initial Comment:
Under TOS 1.04 (Rainbow TOS), even patched, the font selector displays then crash.

With or without NVDI, 

To reproduce the problem, you can try the Font Selector in the Windom demo. I tried calling it from my own programs, same result.
Tried on Mega ST and a ST with TOS 1.04.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=521411&aid=3404565&group_id=68507

Am Do, 17.02.2011, 06:39 schrieb arn...@fr...:

> Maybe some stuff have been fixed on CVS sf.net so that compilation of
> windom with gcc 3 and then gcc 4 works without error. I don't remember...
> and maybe these fixes are not in the RPM source.

Hello,

just wanted to tell: yes, the cvs version compiles without errors on with
the native gcc4.x :)

On Sat, 19 Feb 2011 13:49:50 , m0n0 <ol...@mo...> wrote:
>
>
> > EzXML can read and write XML files easily and I remembered
> > that OpenOffice uses XML for spreadsheet files, so there is
> > a well defined format.
>
>  LibXML2 would be more suitable for that task...

Has it been ported ?

> > Texel is ok but old and unsupported so I wondered if we could
> > build a simple, opensource spreadsheet based on this XML format ?
>
>  I like texel ;)

Me too, I use it quite a bit but it's not going to get better.

> > Loading the data the data should be ok, someone must know about
> > displaying the table cells and then there is the tricky matter of
> > parsing and processing the formulae.
>
>  That's s...load of work! Do you have the time to do it?
>
Yes I know but it is an interesting idea. Mayve the calc algorithm
could be borrowed from another open source project ?

I wouldn't expect all the bells and whistles, something at about the
Texel level would be an excellent target.

Peter

> EzXML can read and write XML files easily and I remembered
> that OpenOffice uses XML for spreadsheet files, so there is
> a well defined format.

 LibXML2 would be more suitable for that task...

> Texel is ok but old and unsupported so I wondered if we could
> build a simple, opensource spreadsheet based on this XML format ?

 I like texel ;)

> Loading the data the data should be ok, someone must know about
> displaying the table cells and then there is the tricky matter of
> parsing and processing the formulae.

 That's s...load of work! Do you have the time to do it?

 Greets,
 m

In an idle moment yesterday a thought occurred to me.

EzXML can read and write XML files easily and I remembered
that OpenOffice uses XML for spreadsheet files, so there is
a well defined format.

Texel is ok but old and unsupported so I wondered if we could
build a simple, opensource spreadsheet based on this XML format ?

Loading the data the data should be ok, someone must know about
displaying the table cells and then there is the tricky matter of
parsing and processing the formulae.

Peter

Hello,

> I remember that I also got this error during cross compilation, but if
> I 
> mind correctly, this was within some auto-generated file? hm... Did
> you 
> compile the RPM or do you use some other package specially crafted for 
> Cross-Compiling?

I just cross-compile windom source code available on sf.net (cvs)

Maybe some stuff have been fixed on CVS sf.net so that compilation of windom with gcc 3 and then gcc 4 works without error. I don't remember... and maybe these fixes are not in the RPM source.

Hope this helps...

Arnaud.

On 16.02.2011 20:12, Arnaud BERCEGEAY wrote:
>
> Hmm... i just "make clean" and "make cross" on windom source code... and
> it compiles fine with GCC 4.5.2 (i use cross-gcc provided by Vincent).
>
>
I remember that I also got this error during cross compilation, but if I 
mind correctly, this was within some auto-generated file? hm... Did you 
compile the RPM or do you use some other package specially crafted for 
Cross-Compiling?

Greets,
m

Hello,

Le 15/02/2011 23:06, m0n0 a écrit :
>
>   Hello,
>
>   the mint windom RPM fails with the latest GCC ( 4.x ).
>
>   objc_attach.c:235 - error: lvalue required as left operand of
>   assignment.

Hmm... i just "make clean" and "make cross" on windom source code... and 
it compiles fine with GCC 4.5.2 (i use cross-gcc provided by Vincent).

Arnaud.

 Hello,

 the mint windom RPM fails with the latest GCC ( 4.x ).

 objc_attach.c:235 - error: lvalue required as left operand of 
 assignment.

 This is the problem also happens with AHCM when compiled with GCC.

 with windom it looks like this:
 (void*)bind[index].desc.func.f.form = (void*)va_arg( arg, void*);

 I don't know how to fix that properly. If someone knows how to fix it, 
 please let me know...

 Greets,
 m

Hello,

Le 25/01/2011 20:56, Peter Slegg a écrit :
> When using DFRM is there a quick and easy way to create a fileselector
> button and field ?
>

AFAIK, no... i mean : yes but it's not in dfrm ATM.

If you mean a button with a filename inside, which calls the AES 
fileselector (FselInput()) when the button is selected, well... i don't 
think it's a so heavy work to code (mainly some strcpy/strcat stuff).

BTW, you're right, this may be something usefull for others and it's 
quite generic... so it may be added to dfrm (IMO).

Arnaud.

When using DFRM is there a quick and easy way to create a fileselector
button and field ?

Regards,

Peter

Hi all,

I've not done a great deal on gentool but I have just added the basis
of creating config files.

http://www.p.slegg.scubadivers.co.uk/download/gentool.zip

Start it with the config.xml and it creates a simple config with some
XaAES settings, as an example.

XaAES has some unusual config settings and I am not sure how best to
handle them, even the seemingly simple ones. Should they be commented
out to turn them off or set to "off" or whatever ?

Ideally gentool would also load the real config file and use that to
set-up the dialogue and then re-write it with the user changes. One
step at a time though.

Regards,
Peter

Hello,

>  I'm using window 2.0.0-rc2, I know that there is also an 2.0.1-rc1 
>  around.... Maybe the bug is fixed there? Don't know, but the

Just a side note:

windom 2.0.0-rc1 and 2.0.0-rc2 were 2 release candidate (rc) of windom 2.
Then, the final version of windom 2.0.0 has been released.
Then, windom 2.0.1 has been released (no Release Candidate version for windom 2.0.1).

http://sourceforge.net/projects/windom/files/windom/

Arnaud.

Hello,

>  Is it possible to update the SVN / CVS when I (or some other person)
>  got an bugfix for this? How to do it? My solution will probably be an

Of course... Just submit a patch here.
If you want to contribute a bit more on windom, i can give you write access to the CVS.

BTW, it would be better if the real root cause of the problem is understood and fixed. Just a "patch" to hide the bug is not really a good solution IMO.

There are also a bug tracker on sf.net (links on windom home page) to log that kind of bug.

Arnaud.

 Hello,

 I found a bug within the component window interface...
 I'm using window 2.0.0-rc2, I know that there is also an 2.0.1-rc1 
 around.... Maybe the bug is fixed there? Don't know, but the 2.0.0-rc2 
 contains a folder "examples" which is not availabe within the 2.0.1-rc1 
 package...

 The Bug just triggers with aranym or my plain falcon - it DOES NOT 
 trigger with aranym-jit.

 examples\frames\wdiff.prg can be used as a test-case for this bug. 
 During comp_wind_create there is an "loose focus" event triggered.
 within the function comp_focus_change the passed COMPONENT * is 1 - 
 doesn't look like an valid pointer ;). Currently I'm investigating the 
 problem... But maybe someone can tell about it? Anyone knows other 
 architectures that trigger the bug?

 Is it possible to update the SVN / CVS when I (or some other person) 
 got an bugfix for this? How to do it? My solution will probably be an 
 check for an NULL pointer somewhere, although this is not the real 
 deal... because the Bug is caused by some logic,... but I guess it can 
 be calmed that way...

 Greets,
 m

Le Tue, 21 Dec 2010 13:47:28 +0200 (GMT),
Peter Slegg <p....@sc...> a écrit :

Dear Peter (and Windom-list users),

You right, there is a bug (in DFRM) when one binds a variable to a radio
button, and I just have fixed it. The problem was in
mt_dfrm_win_attach() which did not call correctly mt_ObjctAttach().

I will update tonite the CVS repository. I will update the autotool
package I made for DFRM (available on my home page
pequan.lip6.fr/~bereziat/softs/tos/cross-compilation/index.html, which
is ready to use for cross-compilation and linux packaging).

I can send you directly the patch, if you are impatient.

Regards.

> On Sun, 19 Dec 2010 15:04:38 , Peter Slegg
> <p....@sc...> wrote:
> >
> > Thanks, I now have BIND_BIT radio buttons working and I'll try again
> > with BIND_VAR but I would like to sort out the layout a bit first.
> >
> 
> I just tried BIND_VAR in a small test app using an array to hold
> each radio button variable. Oddly it is working. I had tried this
> before without success.
> 
> :-)
> 
> Peter
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Windom-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/windom-users

-- 
Dominique Béréziat
Maître de Conférences / Associate Professor
Université Pierre et Marie Curie 
Laboratoire d'Informatique Paris 6
tel : +33 1 44 27 47 71
fax : +33 1 44 27 75 41

Hi,

Excellent, at least I am not going mad :-)

No hurry for me. Not planning to do much on this for a few days.
I worked around the problem so I could progress on other things
but I need to do some more thinking/designing and I am learning
as I go.

Thanks,

Peter

On Tue, 21 Dec 2010 15:09:35 , Dominique Béréziat wrote:
>
> Le Tue, 21 Dec 2010 13:47:28 +0200 (GMT),
> Peter Slegg <p....@sc...> a écrit :
>
> Dear Peter (and Windom-list users),
>
> You right, there is a bug (in DFRM) when one binds a variable to a radio
> button, and I just have fixed it. The problem was in
> mt_dfrm_win_attach() which did not call correctly mt_ObjctAttach().
>
> I will update tonite the CVS repository. I will update the autotool
> package I made for DFRM (available on my home page
> pequan.lip6.fr/~bereziat/softs/tos/cross-compilation/index.html, which
> is ready to use for cross-compilation and linux packaging).
>
> I can send you directly the patch, if you are impatient.
>
> Regards.
>
>
> > On Sun, 19 Dec 2010 15:04:38 , Peter Slegg
> > <p....@sc...> wrote:
> > >
> > > Thanks, I now have BIND_BIT radio buttons working and I'll try again
> > > with BIND_VAR but I would like to sort out the layout a bit first.
> > >
> >
> > I just tried BIND_VAR in a small test app using an array to hold
> > each radio button variable. Oddly it is working. I had tried this
> > before without success.
> >
> > :-)
> >
> > Peter
> >
> >

On Sun, 19 Dec 2010 15:04:38 , Peter Slegg <p....@sc...> wrote:
>
> Thanks, I now have BIND_BIT radio buttons working and I'll try again
> with BIND_VAR but I would like to sort out the layout a bit first.
>

I just tried BIND_VAR in a small test app using an array to hold
each radio button variable. Oddly it is working. I had tried this
before without success.

:-)

Peter

Hi all,

Thanks for the hints. I have got some of the features working in
gentool.

http://www.p.slegg.scubadivers.co.uk/download/gentool.zip

Start it by dropping the xml file onto the .app or associate
*.xml with gentool and double-click ls.xml

The check-boxes set the switches that are passed to ls (this
is a simple demo obviously). The radio buttons don't do anything
yet, tomorrow maybe.

It has a lot of limitations and the C code is far from perfect
and probably needs more idiot traps so any tips gratefully received.

Regards,

Peter

Le Mon, 20 Dec 2010 12:40:28 +0200 (GMT),
Peter Slegg <p....@sc...> a écrit :

Hi Peter,

and sorry for this long silence ...
could you send the full source file ?

Regards.

> On Mon, 20 Dec 2010 12:32:52 , Peter Slegg
> <p....@sc...> wrote:
> > Attached you can see how it currently works with a main box (blue)
> > and two inner ones. Slightly confused by the radio group.
> >
> > I'll change the code back to the simpler design and see how it
> > looks.
> >
> > Peter
> >
> 
> This is the earlier design with two boxes in ROOT.
> 
>   dfrm_add( dial, ROOT, parentBox, -4, 0, DIR_VERT);
>   dfrm_add( dial, ROOT, buttonbox, -4, 0, DIR_VERT);
> 
>   dfrm_align( dial, parentBox, DIR_VERT, ALIGN_LEFT);
>   dfrm_align( dial, buttonbox, DIR_VERT, ALIGN_CENTER);
> 
>   dfrm_repack( dial);
> 
> Changing both to ALIGN_LEFT puts the large buttons at the
> top of the dialogue overwriting the label underneath.
> 
> Regards,
> 
> Peter
> 
> 
> 

-- 
Dominique Béréziat
Maître de Conférences / Associate Professor
Université Pierre et Marie Curie 
Laboratoire d'Informatique Paris 6
tel : +33 1 44 27 47 71
fax : +33 1 44 27 75 41

On Mon, 20 Dec 2010 12:32:52 , Peter Slegg <p....@sc...> wrote:
> Attached you can see how it currently works with a main box (blue) and two
> inner ones. Slightly confused by the radio group.
>
> I'll change the code back to the simpler design and see how it looks.
>
> Peter
>

This is the earlier design with two boxes in ROOT.

  dfrm_add( dial, ROOT, parentBox, -4, 0, DIR_VERT);
  dfrm_add( dial, ROOT, buttonbox, -4, 0, DIR_VERT);

  dfrm_align( dial, parentBox, DIR_VERT, ALIGN_LEFT);
  dfrm_align( dial, buttonbox, DIR_VERT, ALIGN_CENTER);

  dfrm_repack( dial);

Changing both to ALIGN_LEFT puts the large buttons at the
top of the dialogue overwriting the label underneath.

Regards,

Peter

On Sun, 19 Dec 2010 23:24:11 , Arnaud BERCEGEAY <arn...@fr...> wrote:
> Hello,
>
> > I think it might not be allowed to add more than one box to ROOT.
> > By creating a third box to contain the first two it seems to work.
>
> Hmm... i've already created some forms with a lot of objects added to
> ROOT, and it worked as expected.
>
> Could you please replace "invisible" boxes by "visible" boxes in order
> to understand what DFRM does ? The goal of this test is to understand
> the problem, and fix it in DFRM (or maybe in your code ;) or to add a
> "known bug/work around" in DFRM documentation.
>
> BTW, it seems that you finally get DFRM rendering the form as expected,
> and that's good news.
>
Attached you can see how it currently works with a main box (blue) and two
inner ones. Slightly confused by the radio group.

I'll change the code back to the simpler design and see how it looks.

Peter

2004	Jan	Feb	Mar	Apr	May	Jun	Jul (5)	Aug (12)	Sep (11)	Oct	Nov (2)	Dec (1)
2005	Jan	Feb (48)	Mar (10)	Apr (6)	May	Jun	Jul (3)	Aug (4)	Sep	Oct (25)	Nov (45)	Dec (75)
2006	Jan (52)	Feb (41)	Mar (27)	Apr (14)	May (21)	Jun (7)	Jul	Aug (6)	Sep (1)	Oct (12)	Nov (5)	Dec (5)
2007	Jan (5)	Feb (4)	Mar (4)	Apr (9)	May (2)	Jun (1)	Jul (2)	Aug (1)	Sep	Oct	Nov (3)	Dec (4)
2008	Jan	Feb	Mar	Apr	May	Jun (13)	Jul (7)	Aug	Sep	Oct	Nov	Dec (5)
2009	Jan	Feb (2)	Mar (4)	Apr	May (9)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2010	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (5)	Sep (14)	Oct (4)	Nov	Dec (22)
2011	Jan (3)	Feb (8)	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct (3)	Nov	Dec

windom-users Mailing List for WinDom, a high level GEM library.

windom-users — Mailing list devoted to WinDom users and developpers interactions