From kennetha at stud.ntnu.no  Sat Oct  6 07:32:21 2007
From: kennetha at stud.ntnu.no (Kenneth Juul)
Date: Sat, 6 Oct 2007 13:32:21 +0200
Subject: [fxruby-users] Updating GUI while doing slow IO-operations
In-Reply-To: <f28bc50f0709220442j40949d71ya14f691676e5d5d3@mail.gmail.com>
References: <f28bc50f0709192359k4488eb49ua56bc7c287543657@mail.gmail.com>
	<7BC6C321-B704-4601-A54B-5A431257C628@lylejohnson.name>
	<f28bc50f0709220442j40949d71ya14f691676e5d5d3@mail.gmail.com>
Message-ID: <f28bc50f0710060432j3c69d6f1x402c5ecf20cf7af0@mail.gmail.com>

I've tried the easy way out, Lyle's suggestion using FXApp::addInput.
It seems like this does NOT do the trick.

I'll post the solution that works, if I can make it that is.

Regards,
K

On 9/22/07, Kenneth Juul <kennetha at stud.ntnu.no> wrote:
> Thanks for your answers guys,
> I have not yet tried your suggestions, but I will.
>
> I'll let you know as soon as I do.
>
> K.
>
>
> On 9/21/07, Lyle Johnson <lyle at lylejohnson.name> wrote:
> >
> > On Sep 20, 2007, at 1:59 AM, Kenneth Juul wrote:
> >
> > > I have made a rather large program in Ruby for use in Windows. The
> > > user interface is made with fxruby, of course. The program is
> > > "talking" to a small embedded computer over both serial and ethernet
> > > interfaces. Some of this communication is taking a while, several
> > > minutes actually, and this is when my problem occurs:
> > >
> > > During slow, time consuming operations, the GUI freezes / hangs.
> > > Sometimes it just turn "windows-white" and stays like this until the
> > > IO is done, other times it just freezes the last window until IO is
> > > done.
> > >
> > > I have done some vague attempts on starting of the IO withing separate
> > > threads without any improvement. I also have tried some calls to
> > > flush(), forceRefresh(), refresh(), update() and so on, without any
> > > improvement.
> > >
> > > Enlighten me please!
> >
> > The problem with using Ruby threads for the I/O is that they'll block
> > the whole application. You might be able to use the FXApp#addInput
> > API (see the input.rb example program), although I've never tried to
> > use it with network I/O.
> > _______________________________________________
> > fxruby-users mailing list
> > fxruby-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/fxruby-users
> >
> >
>
>
> --
> Mvh
> Kenneth Juul
>
> mob/tlf 99008269 / 73514449
>


-- 
Med vennlig hilsen
Kenneth Juul

From philippe.lang at attiksystem.ch  Mon Oct  8 02:12:51 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Mon, 8 Oct 2007 08:12:51 +0200
Subject: [fxruby-users] FXRuby default error handler
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>

Hi,

I'm using FXRuby for building a database front-end. I have quite a lot
of classes now, made up of multiple methods each. Most of the time I use
rescue blocks in case an exception is raised by the framemork. But doing
that in every method of every class is really tedious. 

If an exception is raised from a method without a rescue block, the
problem is that my application quits, since the application "run" method
stops. 


  begin
  
    $app = MyApp.new
    $app.create
    $app.run
    
  rescue Exception => e

    DbError.show("", e)

  end


I was wondering if we could define some sort of "default error handler"
for errors raised from the framework, in order to avoid both the
application crash, and the "one rescue per method" solution...

Thanks!

Philippe Lang

From philippe.lang at attiksystem.ch  Mon Oct  8 07:51:01 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Mon, 8 Oct 2007 13:51:01 +0200
Subject: [fxruby-users] FXTable: how to prevent a particular column from
	being resized?
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF3E@poweredge.attiksystem.ch>

Hi again,

I'm using FXTables with a few hidden columns, which have 0 width.

Is there a way to prevent the user from resizing these columns, which
only have an internal meaning?

Philippe

From jeroen at fox-toolkit.org  Mon Oct  8 08:54:07 2007
From: jeroen at fox-toolkit.org (Jeroen van der Zijp)
Date: Mon, 8 Oct 2007 07:54:07 -0500
Subject: [fxruby-users] FXTable: how to prevent a particular column from
	being resized?
In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CF3E@poweredge.attiksystem.ch>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3E@poweredge.attiksystem.ch>
Message-ID: <200710080754.09154.jeroen@fox-toolkit.org>

On Monday 08 October 2007 06:51, Philippe Lang wrote:
> Hi again,
> 
> I'm using FXTables with a few hidden columns, which have 0 width.
> 
> Is there a way to prevent the user from resizing these columns, which
> only have an internal meaning?

You can disable resizing of rows and/or columns.  However, its an all-or-nothing
thing; you can't turn resizing off for a single row/column only.

I can suggest a sneaky trick, maybe:- as the cursor moves, enable or disable
the resizability based on the column its hovering over.  I admit its not
super elegant but it might work...



	- Jeroen


-- 
+----------------------------------------------------------------------------+
| Copyright (C) 07:40 10/ 8/2007 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

From vjoel at path.berkeley.edu  Mon Oct  8 15:36:39 2007
From: vjoel at path.berkeley.edu (Joel VanderWerf)
Date: Mon, 08 Oct 2007 12:36:39 -0700
Subject: [fxruby-users] FXRuby default error handler
In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>
Message-ID: <470A86C7.7010302@path.berkeley.edu>

Philippe Lang wrote:
> Hi,
> 
> I'm using FXRuby for building a database front-end. I have quite a lot
> of classes now, made up of multiple methods each. Most of the time I use
> rescue blocks in case an exception is raised by the framemork. But doing
> that in every method of every class is really tedious. 
> 
> If an exception is raised from a method without a rescue block, the
> problem is that my application quits, since the application "run" method
> stops. 
> 
> 
>   begin
>   
>     $app = MyApp.new
>     $app.create
>     $app.run
>     
>   rescue Exception => e
> 
>     DbError.show("", e)
> 
>   end
> 
> 
> I was wondering if we could define some sort of "default error handler"
> for errors raised from the framework, in order to avoid both the
> application crash, and the "one rescue per method" solution...

That's a good question.

I usually just try to make "one rescue per method" as painless as 
possible, by writing wrapper methods. Still, that's "one wrapper per 
method", which is only a slight improvement.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

From meinrad.recheis at gmail.com  Mon Oct  8 16:56:04 2007
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Mon, 8 Oct 2007 22:56:04 +0200
Subject: [fxruby-users] FXRuby default error handler
In-Reply-To: <470A86C7.7010302@path.berkeley.edu>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>
	<470A86C7.7010302@path.berkeley.edu>
Message-ID: <43d756720710081356g18436225k7fe58d42fffe9f3c@mail.gmail.com>

On 10/8/07, Joel VanderWerf <vjoel at path.berkeley.edu> wrote:
> Philippe Lang wrote:
> > Hi,
> >
> > I'm using FXRuby for building a database front-end. I have quite a lot
> > of classes now, made up of multiple methods each. Most of the time I use
> > rescue blocks in case an exception is raised by the framemork. But doing
> > that in every method of every class is really tedious.
> >
> > If an exception is raised from a method without a rescue block, the
> > problem is that my application quits, since the application "run" method
> > stops.
> >
> >
> >   begin
> >
> >     $app = MyApp.new
> >     $app.create
> >     $app.run
> >
> >   rescue Exception => e
> >
> >     DbError.show("", e)
> >
> >   end
> >
> >
> > I was wondering if we could define some sort of "default error handler"
> > for errors raised from the framework, in order to avoid both the
> > application crash, and the "one rescue per method" solution...
>
> That's a good question.
>
> I usually just try to make "one rescue per method" as painless as
> possible, by writing wrapper methods. Still, that's "one wrapper per
> method", which is only a slight improvement.
>

Try to centralize access to the DB. Channel all method calls to the DB
through one dedicated method that handles db errors. something like
this could do the job:

class DB
def safe_call( method, *args, &block)
self.send( method, *args, &block)
rescue DBError
# all db errorhandling here
end
end

there might be even better solutions

-- meinrad

From philippe.lang at attiksystem.ch  Tue Oct  9 02:15:32 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Tue, 9 Oct 2007 08:15:32 +0200
Subject: [fxruby-users] FXTable: how to prevent a particular column from
	being resized?
References: <6C0CF58A187DA5479245E0830AF84F4218CF3E@poweredge.attiksystem.ch>
	<200710080754.09154.jeroen@fox-toolkit.org>
Message-ID: <6C0CF58A187DA5479245E0830AF84F42337D65@poweredge.attiksystem.ch>

Jeroen van der Zijp wrote:

> On Monday 08 October 2007 06:51, Philippe Lang wrote:
>> Hi again,
>> 
>> I'm using FXTables with a few hidden columns, which have 0 width.
>> 
>> Is there a way to prevent the user from resizing these columns, which
>> only have an internal meaning?
> 
> You can disable resizing of rows and/or columns.  However, its an
> all-or-nothing thing; you can't turn resizing off for a single
> row/column only.  
> 
> I can suggest a sneaky trick, maybe:- as the cursor moves, enable or
> disable the resizability based on the column its hovering over.  I
> admit its not super elegant but it might work...  

I found a very useful workaround: put the zero-width columns at the
extreme left of the FXTable. They cannot be resized there!

Philippe

From philippe.lang at attiksystem.ch  Tue Oct  9 03:13:10 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Tue, 9 Oct 2007 09:13:10 +0200
Subject: [fxruby-users] FXTable: how to prevent a particular column from
	being resized?
References: <6C0CF58A187DA5479245E0830AF84F4218CF3E@poweredge.attiksystem.ch>
	<200710080754.09154.jeroen@fox-toolkit.org>
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF40@poweredge.attiksystem.ch>

Jeroen van der Zijp wrote:

> On Monday 08 October 2007 06:51, Philippe Lang wrote:
>> Hi again,
>> 
>> I'm using FXTables with a few hidden columns, which have 0 width.
>> 
>> Is there a way to prevent the user from resizing these columns, which
>> only have an internal meaning?
> 
> You can disable resizing of rows and/or columns.  However, its an
> all-or-nothing thing; you can't turn resizing off for a single
> row/column only.  
> 
> I can suggest a sneaky trick, maybe:- as the cursor moves, enable or
> disable the resizability based on the column its hovering over.  I
> admit its not super elegant but it might work...  

Hi again,

I think I found a bug while playing with zero-width columns: as soon as
the extreme right column is shrinked to zero width, it cannot be
stretched anymore: when getting to the place where the stretch should
start, the mouse icon is correct, but after the clic, nothing happens.

My configuration:
-----------------
Windows XP
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
fxruby 1.6.11

Test code:
----------

#!/usr/bin/ruby

require 'fox16'

include Fox

class MyWindow < FXMainWindow
    
  def initialize(app)

    super(app, "Window", nil, nil, DECOR_ALL, 0, 0, 600, 350)

    # Menu bar stretched along the top of the main window
    menubar = FXMenuBar.new(self, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)
  
    # File menu
    filemenu = FXMenuPane.new(self)
    FXMenuTitle.new(menubar, "&File", nil, filemenu)
    FXMenuCommand.new(filemenu, "&Quit\tCtl-Q\tQuit the application",
        nil, app, FXApp::ID_QUIT)

    # Table
    f = FXHorizontalFrame.new(self, LAYOUT_FILL_X|LAYOUT_FILL_Y)
    t = FXTable.new(f, nil, 0,
TABLE_COL_SIZABLE|LAYOUT_FILL_X|LAYOUT_FILL_Y)
    
    t.visibleRows = 3
    t.visibleColumns = 3
    t.setTableSize(3, 3)
    
  end

  def create
    super
    show(PLACEMENT_SCREEN)
  end
  
end

if __FILE__ == $0
  application = FXApp.new("Attik System", "FXRuby Test")
  MyWindow.new(application)
  application.create
  application.run
end

From jeroen at fox-toolkit.org  Tue Oct  9 08:34:23 2007
From: jeroen at fox-toolkit.org (Jeroen van der Zijp)
Date: Tue, 9 Oct 2007 07:34:23 -0500
Subject: [fxruby-users] FXTable: how to prevent a particular column from
	being resized?
In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CF40@poweredge.attiksystem.ch>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3E@poweredge.attiksystem.ch>
	<200710080754.09154.jeroen@fox-toolkit.org>
	<6C0CF58A187DA5479245E0830AF84F4218CF40@poweredge.attiksystem.ch>
Message-ID: <200710090734.25256.jeroen@fox-toolkit.org>

On Tuesday 09 October 2007 02:13, Philippe Lang wrote:
> Jeroen van der Zijp wrote:
> 
> > On Monday 08 October 2007 06:51, Philippe Lang wrote:
> >> Hi again,
> >> 
> >> I'm using FXTables with a few hidden columns, which have 0 width.
> >> 
> >> Is there a way to prevent the user from resizing these columns, which
> >> only have an internal meaning?
> > 
> > You can disable resizing of rows and/or columns.  However, its an
> > all-or-nothing thing; you can't turn resizing off for a single
> > row/column only.  
> > 
> > I can suggest a sneaky trick, maybe:- as the cursor moves, enable or
> > disable the resizability based on the column its hovering over.  I
> > admit its not super elegant but it might work...  
> 
> Hi again,
> 
> I think I found a bug while playing with zero-width columns: as soon as
> the extreme right column is shrinked to zero width, it cannot be
> stretched anymore: when getting to the place where the stretch should
> start, the mouse icon is correct, but after the clic, nothing happens.

OK, yes that indeed sounds like a bug; probably, its because there
is no header-item there there's nothing to click on.

I'll try and fix that, for the next FOX patch level.



	Regards,

				Jeroen



-- 
+----------------------------------------------------------------------------+
| Copyright (C) 07:30 10/ 9/2007 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

From philippe.lang at attiksystem.ch  Tue Oct  9 10:51:13 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Tue, 9 Oct 2007 16:51:13 +0200
Subject: [fxruby-users] FXRuby default error handler
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>
	<470A86C7.7010302@path.berkeley.edu>
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch>

fxruby-users-bounces at rubyforge.org wrote:
> Philippe Lang wrote:
>> Hi,
>> 
>> I'm using FXRuby for building a database front-end. I have quite a
>> lot of classes now, made up of multiple methods each. Most of the
>> time I use rescue blocks in case an exception is raised by the
>> framemork. But doing that in every method of every class is really
>> tedious. 
>> 
>> If an exception is raised from a method without a rescue block, the
>> problem is that my application quits, since the application "run"
>> method stops. 
>> 
>> 
>>   begin
>> 
>>     $app = MyApp.new
>>     $app.create
>>     $app.run
>> 
>>   rescue Exception => e
>> 
>>     DbError.show("", e)
>> 
>>   end
>> 
>> 
>> I was wondering if we could define some sort of "default error
>> handler" for errors raised from the framework, in order to avoid
>> both the application crash, and the "one rescue per method"
>> solution... 
> 
> That's a good question.
> 
> I usually just try to make "one rescue per method" as painless as
> possible, by writing wrapper methods. Still, that's "one wrapper per
> method", which is only a slight improvement.  

Hi everyone,

Lyle, do you think it would be possible to add this feature to the FXApp
class: the ability to register some sort of "rescue handler", that can
intercept in the "run" method the exceptions that would otherwise crash
the application? For compatitility, the default handler could simply
raise the exception again, which is what the framework is doing now.

This would be really useful.

Regards,

Philippe Lang

From lyle.johnson at gmail.com  Tue Oct  9 12:24:56 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Tue, 9 Oct 2007 11:24:56 -0500
Subject: [fxruby-users] FXRuby default error handler
In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>
	<470A86C7.7010302@path.berkeley.edu>
	<6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch>
Message-ID: <97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>


On Oct 9, 2007, at 9:51 AM, Philippe Lang wrote:

> Lyle, do you think it would be possible to add this feature to the  
> FXApp
> class: the ability to register some sort of "rescue handler", that can
> intercept in the "run" method the exceptions that would otherwise  
> crash
> the application? For compatitility, the default handler could simply
> raise the exception again, which is what the framework is doing now.

If you will file a bug report (or feature request) about it, I'll  
consider it. I know that it's sometimes difficult to work around  
FOX's error handling mechanisms, since Jeroen just calls exit() on  
most errors; but particular circumstance may not be affected by that.

From vjoel at path.berkeley.edu  Tue Oct  9 13:36:17 2007
From: vjoel at path.berkeley.edu (Joel VanderWerf)
Date: Tue, 09 Oct 2007 10:36:17 -0700
Subject: [fxruby-users] FXRuby default error handler
In-Reply-To: <97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>	<470A86C7.7010302@path.berkeley.edu>	<6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch>
	<97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>
Message-ID: <470BBC11.9070707@path.berkeley.edu>

Lyle Johnson wrote:
> On Oct 9, 2007, at 9:51 AM, Philippe Lang wrote:
> 
>> Lyle, do you think it would be possible to add this feature to the  
>> FXApp
>> class: the ability to register some sort of "rescue handler", that can
>> intercept in the "run" method the exceptions that would otherwise  
>> crash
>> the application? For compatitility, the default handler could simply
>> raise the exception again, which is what the framework is doing now.
> 
> If you will file a bug report (or feature request) about it, I'll  
> consider it. I know that it's sometimes difficult to work around  
> FOX's error handling mechanisms, since Jeroen just calls exit() on  
> most errors; but particular circumstance may not be affected by that.

I don't think Philippe is talking about those kinds of situations (that 
cause Fox to call exit()), but rather situations where ruby callback 
raises a ruby exception, and it propagates outside of the #run call.

Is there any reason why the following code won't work?

   begin
     app.run
   rescue => ex
     if ... # ex can be retried
       retry
     end
   end
   app.exit

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

From philippe.lang at attiksystem.ch  Wed Oct 10 02:06:50 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Wed, 10 Oct 2007 08:06:50 +0200
Subject: [fxruby-users] FXRuby default error handler
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>	<470A86C7.7010302@path.berkeley.edu>	<6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch><97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>
	<470BBC11.9070707@path.berkeley.edu>
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF42@poweredge.attiksystem.ch>

fxruby-users-bounces at rubyforge.org wrote:
> Lyle Johnson wrote:
>> On Oct 9, 2007, at 9:51 AM, Philippe Lang wrote:
>> 
>>> Lyle, do you think it would be possible to add this feature to the
>>> FXApp class: the ability to register some sort of "rescue handler",
>>> that can intercept in the "run" method the exceptions that would
>>> otherwise crash the application? For compatitility, the default
>>> handler could simply raise the exception again, which is what the
>>> framework is doing now.
>> 
>> If you will file a bug report (or feature request) about it, I'll
>> consider it. I know that it's sometimes difficult to work around
>> FOX's error handling mechanisms, since Jeroen just calls exit() on
>> most errors; but particular circumstance may not be affected by that.
> 
> I don't think Philippe is talking about those kinds of situations
> (that cause Fox to call exit()), but rather situations where ruby
> callback raises a ruby exception, and it propagates outside of the
> #run call.   
> 
> Is there any reason why the following code won't work?
> 
>    begin
>      app.run
>    rescue => ex
>      if ... # ex can be retried
>        retry
>      end
>    end
>    app.exit

Hi Joel,

This is exactly the kind of thing I was takling about, yes, and it works
pretty well, but not 100%, apparently. I'm not sure an FXApp can be
"re-run" that way, without taking risks. Is that true Joeroen?

In my tests, I have noticed for example that an FXTabBook, after an
exception caught by your technique, has got "zombie" pages in it: the
place is still allocated for a page tab, but no page tab is visible at
all. 

I also tried that, but without success:

    begin
      app.repaint
      app.forceRefresh
      app.flush
      app.run
    rescue Exception => e
      ---> show error to the user
      retry
    end
    app.exit

Philippe

From vjoel at path.berkeley.edu  Wed Oct 10 14:47:13 2007
From: vjoel at path.berkeley.edu (Joel VanderWerf)
Date: Wed, 10 Oct 2007 11:47:13 -0700
Subject: [fxruby-users] FXRuby default error handler
In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CF42@poweredge.attiksystem.ch>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>	<470A86C7.7010302@path.berkeley.edu>	<6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch><97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>	<470BBC11.9070707@path.berkeley.edu>
	<6C0CF58A187DA5479245E0830AF84F4218CF42@poweredge.attiksystem.ch>
Message-ID: <470D1E31.4080009@path.berkeley.edu>

Philippe Lang wrote:
> fxruby-users-bounces at rubyforge.org wrote:
,,,
>> Is there any reason why the following code won't work?
>>
>>    begin
>>      app.run
>>    rescue => ex
>>      if ... # ex can be retried
>>        retry
>>      end
>>    end
>>    app.exit
> 
> Hi Joel,
> 
> This is exactly the kind of thing I was takling about, yes, and it works
> pretty well, but not 100%, apparently. I'm not sure an FXApp can be
> "re-run" that way, without taking risks. Is that true Joeroen?
> 
> In my tests, I have noticed for example that an FXTabBook, after an
> exception caught by your technique, has got "zombie" pages in it: the
> place is still allocated for a page tab, but no page tab is visible at
> all. 

The reason I thought it *should* work is that FXApp::run() and 
FXApp::runWhileEvents() are doing basically the same thing, with 
slightly different logic. So if it is safe to unwind from runWhileEvents 
and then re-enter the event loop, then it should be safe to do so with 
run as well.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

From meinrad.recheis at gmail.com  Thu Oct 11 03:47:59 2007
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Thu, 11 Oct 2007 09:47:59 +0200
Subject: [fxruby-users] FXRuby default error handler
In-Reply-To: <470D1E31.4080009@path.berkeley.edu>
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>
	<470A86C7.7010302@path.berkeley.edu>
	<6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch>
	<97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>
	<470BBC11.9070707@path.berkeley.edu>
	<6C0CF58A187DA5479245E0830AF84F4218CF42@poweredge.attiksystem.ch>
	<470D1E31.4080009@path.berkeley.edu>
Message-ID: <43d756720710110047t2edc4b28ybef34bbe73d8231e@mail.gmail.com>

On 10/10/07, Joel VanderWerf <vjoel at path.berkeley.edu> wrote:
> Philippe Lang wrote:
> > fxruby-users-bounces at rubyforge.org wrote:
> ,,,
> >> Is there any reason why the following code won't work?
> >>
> >>    begin
> >>      app.run
> >>    rescue => ex
> >>      if ... # ex can be retried
> >>        retry
> >>      end
> >>    end
> >>    app.exit
> >
> > Hi Joel,
> >
> > This is exactly the kind of thing I was takling about, yes, and it works
> > pretty well, but not 100%, apparently. I'm not sure an FXApp can be
> > "re-run" that way, without taking risks. Is that true Joeroen?
> >
> > In my tests, I have noticed for example that an FXTabBook, after an
> > exception caught by your technique, has got "zombie" pages in it: the
> > place is still allocated for a page tab, but no page tab is visible at
> > all.
>
> The reason I thought it *should* work is that FXApp::run() and
> FXApp::runWhileEvents() are doing basically the same thing, with
> slightly different logic. So if it is safe to unwind from runWhileEvents
> and then re-enter the event loop, then it should be safe to do so with
> run as well.
>

... if there weren't all those nasty side effects :P

From philippe.lang at attiksystem.ch  Thu Oct 11 04:57:30 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Thu, 11 Oct 2007 10:57:30 +0200
Subject: [fxruby-users] FXRuby default error handler
References: <6C0CF58A187DA5479245E0830AF84F4218CF3C@poweredge.attiksystem.ch>	<470A86C7.7010302@path.berkeley.edu>	<6C0CF58A187DA5479245E0830AF84F4218CF41@poweredge.attiksystem.ch><97D8F2CC-C99F-47F2-82E1-C917E383D4EA@gmail.com>	<470BBC11.9070707@path.berkeley.edu><6C0CF58A187DA5479245E0830AF84F4218CF42@poweredge.attiksystem.ch>
	<470D1E31.4080009@path.berkeley.edu>
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF45@poweredge.attiksystem.ch>

fxruby-users-bounces at rubyforge.org wrote:

>>> Is there any reason why the following code won't work?
>>> 
>>>    begin
>>>      app.run
>>>    rescue => ex
>>>      if ... # ex can be retried
>>>        retry
>>>      end
>>>    end
>>>    app.exit
>> 
>> Hi Joel,
>> 
>> This is exactly the kind of thing I was takling about, yes, and it
>> works pretty well, but not 100%, apparently. I'm not sure an FXApp
>> can be "re-run" that way, without taking risks. Is that true Joeroen?
>> 
>> In my tests, I have noticed for example that an FXTabBook, after an
>> exception caught by your technique, has got "zombie" pages in it: the
>> place is still allocated for a page tab, but no page tab is visible
>> at all.
> 
> The reason I thought it *should* work is that FXApp::run() and
> FXApp::runWhileEvents() are doing basically the same thing, with
> slightly different logic. So if it is safe to unwind from
> runWhileEvents and then re-enter the event loop, then it should be
> safe to do so with run as well.   

OK, I managed to reduce my problem to the following test program: as
soon as you try to add a "buggy tab", the GUI starts to mess up. The
result, you will see, is different if you start by adding a buggy tab,
or if you start by adding a normal tab.

Maybe I need to call some kind of "refresh" after the exception is
raised?

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

#!/usr/bin/ruby

require 'fox16'

include Fox

class MyFXTabItem < FXTabItem
	
end

class MyBuggyFXTabItem < FXTabItem
  def initialize(text, icon=nil, data=nil)
  	super
  	raise Exception.new
  end
end

class MyWindow < FXMainWindow
    
  def initialize(app)

    super(app, "Window", nil, nil, DECOR_ALL, 0, 0, 600, 350)

    # Menu bar stretched along the top of the main window
    menubar = FXMenuBar.new(self, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)
  
    # File menu
    filemenu = FXMenuPane.new(self)
    FXMenuTitle.new(menubar, "&File", nil, filemenu)
    FXMenuCommand.new(filemenu, "&Quit\tCtl-Q\tQuit the application",
        nil, app, FXApp::ID_QUIT)

    # Content
    contents = FXVerticalFrame.new(self, LAYOUT_FILL_X|LAYOUT_FILL_Y)
      
    # Tabs
    @tabbook = FXTabBook.new(contents,:opts =>
LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_RIGHT)
      
    FXButton.new(contents, "add tab").connect(SEL_COMMAND) do |sender,
selector, data|
	    # First item is a list
	    tab = MyFXTabItem.new(@tabbook, "&Simple List", nil)
	    frame = FXHorizontalFrame.new(@tabbook,
FRAME_THICK|FRAME_RAISED)
	    simplelist = FXList.new(frame, :opts =>
LIST_EXTENDEDSELECT|LAYOUT_FILL_X|LAYOUT_FILL_Y)
	    simplelist.appendItem("First Entry")
	    simplelist.appendItem("Second Entry")
	    simplelist.appendItem("Third Entry")
	    simplelist.appendItem("Fourth Entry")
	    
	    frame.create
	    tab.create
	    tab.show
	end
	
	FXButton.new(contents, "add buggy tab").connect(SEL_COMMAND) do
|sender, selector, data|
	    # Second item is a file list
	    tab = MyBuggyFXTabItem.new(@tabbook, "F&ile List", nil)
	    frame = FXHorizontalFrame.new(@tabbook,
FRAME_THICK|FRAME_RAISED)
	    filelist = FXFileList.new(frame, :opts =>
ICONLIST_EXTENDEDSELECT|LAYOUT_FILL_X|LAYOUT_FILL_Y)
	    
	    frame.create
	    tab.create
	    tab.show
	end
  
  end

  def create
    super
    show(PLACEMENT_SCREEN)
  end
  
end

if __FILE__ == $0
	
  $app = FXApp.new("Attik System", "FXRuby Test")
  MyWindow.new($app)
  $app.create
  
  begin
    $app.run
  rescue Exception => e
    FXMessageBox.information($app, MBOX_OK, "Error", "An exception was
raised")
    retry
  end
end

From philippe.lang at attiksystem.ch  Fri Oct 12 05:44:31 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Fri, 12 Oct 2007 11:44:31 +0200
Subject: [fxruby-users] Scrolling to the newly appended row in an FXTable
Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CF48@poweredge.attiksystem.ch>

Hi,

After appending a row in an FXTable, I'd like to scroll the FXTable to
the last line of the FXTable, to make sure the new row is visible.

I'm using this kind of code:

  def onInsertRow(sender, sel, ptr)
  	@table.appendRows(1, true)
  	@table.setPosition(0, -1000) # I never have more that 1000 lines
in the table!
  end

The problem is that I'm unable to scroll until the last line, only the
line *** before the last line ***. Apparently, it's a "timing" problem:
when position is set, the line append is not completely "committed" to
the GUI.

Called separately, @table.setPosition(0, -1000) works just fine, as you
can see in this test:

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

#!/usr/bin/env ruby

require 'fox16'
require 'date'

include Fox

class TableWindow < FXMainWindow

  def initialize(app)
    # Call the base class initializer first
    super(app, "Table Widget Test", :opts => DECOR_ALL)

    # Tooltip
    tooltip = FXToolTip.new(getApp())
    
    # Menubar
    menubar = FXMenuBar.new(self, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)
    
    # Separator
    FXHorizontalSeparator.new(self,
LAYOUT_SIDE_TOP|LAYOUT_FILL_X|SEPARATOR_GROOVE)
  
    # Contents
    contents = FXVerticalFrame.new(self,
LAYOUT_SIDE_TOP|FRAME_NONE|LAYOUT_FILL_X|LAYOUT_FILL_Y)
    
    frame = FXVerticalFrame.new(contents,
      FRAME_SUNKEN|FRAME_THICK|LAYOUT_FILL_X|LAYOUT_FILL_Y, :padding =>
0)
  
    # Table
    @table = FXTable.new(frame,
      :opts =>
TABLE_COL_SIZABLE|TABLE_ROW_SIZABLE|LAYOUT_FILL_X|LAYOUT_FILL_Y,
      :padding => 2)
      
    @table.visibleRows = 10
    @table.visibleColumns = 4

    @table.setTableSize(20, 14)

    # Initialize column headers
    (0...12).each  { |c| @table.setColumnText(c, Date::MONTHNAMES[c+1])
}
    
    # Initialize row headers
    (0...20).each { |r| @table.setRowText(r, "Row#{r}") }
    
    # File Menu
    filemenu = FXMenuPane.new(self)
    FXMenuCommand.new(filemenu, "&Quit\tCtl-Q", nil, getApp(),
FXApp::ID_QUIT)
    FXMenuTitle.new(menubar, "&File", nil, filemenu)
    
    # Manipulations Menu
    manipmenu = FXMenuPane.new(self)

    FXMenuCommand.new(manipmenu, "Insert Row").connect(SEL_COMMAND,
method(:onInsertRow))
    FXMenuCommand.new(manipmenu, "Go to last row").connect(SEL_COMMAND,
method(:onCmdGoToLastRow))

    FXMenuTitle.new(menubar, "&Manipulations", nil, manipmenu)

  end
  
  def onCmdGoToLastRow(sender, sel, ptr)
  	@table.setPosition(0, -1000)
  end
  
  def onInsertRow(sender, sel, ptr)
  	@table.appendRows(1, true)
  	@table.setPosition(0, -1000)
  end

  # Create and show this window
  def create
    super
    show(PLACEMENT_SCREEN)
  end
end

# Start the whole thing
if __FILE__ == $0
  # Make application
  application = FXApp.new("TableApp", "FoxTest")
  
  # Make window
  TableWindow.new(application)
  
  # Create app
  application.create
  
  # Run
  application.run
end

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

Any idea how I can do that?

Thanks!

Philippe Lang

From lists at ruby-forum.com  Mon Oct 15 00:55:03 2007
From: lists at ruby-forum.com (SpringFlowers AutumnMoon)
Date: Mon, 15 Oct 2007 06:55:03 +0200
Subject: [fxruby-users] the real deal with Tk on Mac
Message-ID: <ac00f14be93ab37e000fb947f6671a17@ruby-forum.com>

this is really about Tk on Mac...  I find it so easy to use Ruby on the
Mac -- it is pre-installed.  but to get Tk to work, I just can't...

installed ActiveTcl on the Mac and still not work.
-- 
Posted via http://www.ruby-forum.com/.

From lyle.johnson at gmail.com  Mon Oct 15 05:33:33 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Mon, 15 Oct 2007 04:33:33 -0500
Subject: [fxruby-users] the real deal with Tk on Mac
In-Reply-To: <ac00f14be93ab37e000fb947f6671a17@ruby-forum.com>
References: <ac00f14be93ab37e000fb947f6671a17@ruby-forum.com>
Message-ID: <9E739EF9-B114-48F9-86B6-7A4FC28BCDB5@gmail.com>


On Oct 14, 2007, at 11:55 PM, SpringFlowers AutumnMoon wrote:

> this is really about Tk on Mac...  I find it so easy to use Ruby on  
> the
> Mac -- it is pre-installed.  but to get Tk to work, I just can't...
>
> installed ActiveTcl on the Mac and still not work.
> -- 
> Posted via http://www.ruby-forum.com/.

Don't post questions about Tk to the FXRuby list.

From meinrad.recheis at gmail.com  Wed Oct 17 07:46:01 2007
From: meinrad.recheis at gmail.com (Meinrad Recheis)
Date: Wed, 17 Oct 2007 13:46:01 +0200
Subject: [fxruby-users] suggesting a fix for two annoying features
Message-ID: <43d756720710170446w3f81eb6fw9a6c637e95535efe@mail.gmail.com>

lyle,

there are two things that happen regularly when coding fxruby (and
tend to confuse newbies):
1) a widget is accidentally initialized with parent==nil which results
in an exit without a trace where it happened. annoying.
2) a widget that is initialized as child of a parent that is already
created is not displayed if we forget to create it. annoying too.

the following hack fixes both problems. i am using it for a long time
and it saves me a great amount of debugging time. would you like to
add this to fxruby?

class Fox::FXWindow
	def FXWindow.new *args, &block
		window = allocate
		raise TypeError.new("parent must not be nil!") unless args[0]
		window.send(:initialize, *args, &block)
		window.create if window.parent.created?
		return window
	end	
end

cheers,
-- henon

From lyle.johnson at gmail.com  Wed Oct 17 15:55:50 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Wed, 17 Oct 2007 14:55:50 -0500
Subject: [fxruby-users] suggesting a fix for two annoying features
In-Reply-To: <43d756720710170446w3f81eb6fw9a6c637e95535efe@mail.gmail.com>
References: <43d756720710170446w3f81eb6fw9a6c637e95535efe@mail.gmail.com>
Message-ID: <71EFFF88-9B1A-43D2-9E84-714D916B51E5@gmail.com>


On Oct 17, 2007, at 6:46 AM, Meinrad Recheis wrote:

> there are two things that happen regularly when coding fxruby (and
> tend to confuse newbies):
> 1) a widget is accidentally initialized with parent==nil which results
> in an exit without a trace where it happened. annoying.
> 2) a widget that is initialized as child of a parent that is already
> created is not displayed if we forget to create it. annoying too.
>
> the following hack fixes both problems. i am using it for a long time
> and it saves me a great amount of debugging time. would you like to
> add this to fxruby?

I will add bug reports for these, and they may be added in a future  
release.

From lyle.johnson at gmail.com  Thu Oct 18 11:16:05 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Thu, 18 Oct 2007 10:16:05 -0500
Subject: [fxruby-users] [ANN] FXRuby 1.6.12 Now Available
Message-ID: <4D3FA911-5E06-4205-BA46-38F05A31DBD8@gmail.com>

All,

FXRuby is back from an extended summer vacation, with version 1.6.12  
is now available for download from this page:

	http://rubyforge.org/frs/?group_id=300&release_id=15587

Note that if you're building FXRuby from source, you should be using  
FOX 1.6.16 or later due to some important changes made in that  
release of FOX. For a summary of the changes in this release of  
FXRuby, please see this page:

http://www.fxruby.org/doc/changes.html

As usual, the code is provided as a Win32 installer or a binary Gem  
(both compatible with the latest One-Click Installer for Ruby), as a  
source gem, and as a source tarball. For instructions on compiling  
FXRuby from source, please see:

	http://www.fxruby.org/doc/build.html

And as always, the FXRuby home page is here:

	http://www.fxruby.org

Enjoy,

Lyle


From lyle.johnson at gmail.com  Thu Oct 18 16:24:37 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Thu, 18 Oct 2007 15:24:37 -0500
Subject: [fxruby-users] Scrolling to the newly appended row in an FXTable
In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CF48@poweredge.attiksystem.ch>
References: <6C0CF58A187DA5479245E0830AF84F4218CF48@poweredge.attiksystem.ch>
Message-ID: <6793671E-0A79-4009-B2B7-CA9D949C43B5@gmail.com>


On Oct 12, 2007, at 4:44 AM, Philippe Lang wrote:

> After appending a row in an FXTable, I'd like to scroll the FXTable to
> the last line of the FXTable, to make sure the new row is visible.
>
> I'm using this kind of code:
>
>   def onInsertRow(sender, sel, ptr)
>   	@table.appendRows(1, true)
>   	@table.setPosition(0, -1000) # I never have more that 1000 lines
> in the table!
>   end

Philippe,

You just need to add a call to @table.layout() immediately after the  
call to appendRows().

The call to appendRows() marks the layout as dirty, but the layout  
won't actually be recalculated until you return to the event loop.  
Calling layout() explicitly forces the layout to be reconciled right  
away, so that setPosition() has the correct metrics to work with.

Hope this helps,

Lyle


From philippe.lang at attiksystem.ch  Fri Oct 19 01:46:30 2007
From: philippe.lang at attiksystem.ch (Philippe Lang)
Date: Fri, 19 Oct 2007 07:46:30 +0200
Subject: [fxruby-users] Scrolling to the newly appended row in an FXTable
References: <6C0CF58A187DA5479245E0830AF84F4218CF48@poweredge.attiksystem.ch>
	<6793671E-0A79-4009-B2B7-CA9D949C43B5@gmail.com>
Message-ID: <6C0CF58A187DA5479245E0830AF84F42337DB6@poweredge.attiksystem.ch>

fxruby-users-bounces at rubyforge.org wrote:
> On Oct 12, 2007, at 4:44 AM, Philippe Lang wrote:
> 
>> After appending a row in an FXTable, I'd like to scroll the FXTable
>> to the last line of the FXTable, to make sure the new row is visible.
>> 
>> I'm using this kind of code:
>> 
>>   def onInsertRow(sender, sel, ptr)
>>   	@table.appendRows(1, true)
>>   	@table.setPosition(0, -1000) # I never have more that 1000 lines
>>   in the table! end
> 
> Philippe,
> 
> You just need to add a call to @table.layout() immediately after the
> call to appendRows(). 
> 
> The call to appendRows() marks the layout as dirty, but the layout
> won't actually be recalculated until you return to the event loop.
> Calling layout() explicitly forces the layout to be reconciled right
> away, so that setPosition() has the correct metrics to work with.  

Thanks a lot Lyle, it works just fine.

Regards,

Philippe

From lyle.johnson at gmail.com  Sat Oct 20 17:58:01 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Sat, 20 Oct 2007 16:58:01 -0500
Subject: [fxruby-users] [ANN] FXRuby 1.6.12 Now Available
Message-ID: <AC0F7B93-88BB-4A1F-99DE-9F44F835404F@gmail.com>

All,

FXRuby is back from an extended summer vacation, with version 1.6.12  
is now available for download from this page:

	http://rubyforge.org/frs/?group_id=300&release_id=15587

Note that if you're building FXRuby from source, you should be using  
FOX 1.6.16 or later due to some important changes made in that  
release of FOX. For a summary of the changes in this release of  
FXRuby, please see this page:

http://www.fxruby.org/doc/changes.html

As usual, the code is provided as a Win32 installer or a binary Gem  
(both compatible with the latest One-Click Installer for Ruby), as a  
source gem, and as a source tarball. For instructions on compiling  
FXRuby from source, please see:

	http://www.fxruby.org/doc/build.html

And as always, the FXRuby home page is here:

	http://www.fxruby.org

Enjoy,

Lyle


From tom at infoether.com  Sun Oct 21 21:21:18 2007
From: tom at infoether.com (Tom Copeland)
Date: Sun, 21 Oct 2007 21:21:18 -0400
Subject: [fxruby-users] Archiving test...
Message-ID: <1193016078.3534.44.camel@bugs.hal>

...please disregard.

Thanks,

Tom


From lyle.johnson at gmail.com  Sun Oct 21 22:58:33 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Sun, 21 Oct 2007 21:58:33 -0500
Subject: [fxruby-users] [ANN] FXRuby 1.6.12 Now Available (Resend...)
Message-ID: <7A455CC2-CC9F-46AF-AF70-9820464A51CF@gmail.com>

All,

FXRuby is back from an extended summer vacation, with version 1.6.12  
is now available for download from this page:

	http://rubyforge.org/frs/?group_id=300&release_id=15587

Note that if you're building FXRuby from source, you should be using  
FOX 1.6.16 or later due to some important changes made in that  
release of FOX. For a summary of the changes in this release of  
FXRuby, please see this page:

http://www.fxruby.org/doc/changes.html

As usual, the code is provided as a Win32 installer or a binary Gem  
(both compatible with the latest One-Click Installer for Ruby), as a  
source gem, and as a source tarball. For instructions on compiling  
FXRuby from source, please see:

	http://www.fxruby.org/doc/build.html

And as always, the FXRuby home page is here:

	http://www.fxruby.org

Enjoy,

Lyle


From bjorn.bergqvist at gmail.com  Tue Oct 23 16:03:53 2007
From: bjorn.bergqvist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Bergqvist?=)
Date: Tue, 23 Oct 2007 22:03:53 +0200
Subject: [fxruby-users] table.extractText problem
Message-ID: <44936e730710231303r1e51436m1f66d3940c682908@mail.gmail.com>

Hello,
On a linux system with:
ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux]
FXRuby-1.6.12
libfox 1.6.25-1

I tried to use the FXTable::extractText like this

     maxrow = MAX_ROW - 1
      maxcol = MAX_COL - 1
      printout = @table.extractText(0 , maxrow , 0 , maxcol , cs="\t", rs="\n")
      #  Write the file
      File.open(saveDialog.filename, "w").write(printout)

then I got this output:
__________________________________
discretizer.rb:3408: [BUG] Segmentation fault
ruby 1.8.6 (2007-06-07) [i486-linux]
_________________________________

if I change
     maxrow = MAX_ROW - 100
      maxcol = MAX_COL - 100

Then I get:
___________________________________________
*** glibc detected *** ruby: free(): invalid next size (normal): 0x087d3fa8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7d6bd65]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d6f800]
/usr/lib/libFOX-1.6.so.0(_ZN2FX6fxfreeEPPv+0x28)[0xb7203978]
[0x87d3fa8]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:08 1417717    /usr/bin/ruby1.8
08049000-0804a000 rw-p 00000000 08:08 1417717    /usr/bin/ruby1.8
0804a000-08849000 rw-p 0804a000 00:00 0          [heap]
b08f9000-b0902000 r-xp 00000000 08:08 463092
/lib/tls/i686/cmov/libnss_files-2.6.1.so
b0902000-b0904000 rw-p 00008000 08:08 463092
/lib/tls/i686/cmov/libnss_files-2.6.1.so
b0904000-b090c000 r-xp 00000000 08:08 463096
/lib/tls/i686/cmov/libnss_nis-2.6.1.so
b090c000-b090e000 rw-p 00007000 08:08 463096
/lib/tls/i686/cmov/libnss_nis-2.6.1.so
b090e000-b0915000 r-xp 00000000 08:08 463088
/lib/tls/i686/cmov/libnss_compat-2.6.1.so
b0915000-b0917000 rw-p 00006000 08:08 463088
/lib/tls/i686/cmov/libnss_compat-2.6.1.so
b0923000-b0924000 rw-p b0923000 00:00 0
b0924000-b1324000 rwxp b0924000 00:00 0
b1324000-b160e000 rw-p b1324000 00:00 0
b160e000-b360e000 rw-s e8000000 00:0e 18056      /dev/dri/card0
b360e000-b400e000 rw-s e5000000 00:0e 18056      /dev/dri/card0
b400e000-b4a0e000 rw-s e4000000 00:0e 18056      /dev/dri/card0
b4a0e000-b540e000 rw-s 2c008000 00:0e 18056      /dev/dri/card0
b540e000-b5410000 rw-s f8c6f000 00:0e 18056      /dev/dri/card0
b5410000-b5e10000 rw-s e0040000 00:0e 18056      /dev/dri/card0
b5e10000-b603f000 r-xp 00000000 08:08 1414874    /usr/lib/dri/i915_dri.so
b603f000-b604e000 rw-p 0022f000 08:08 1414874    /usr/lib/dri/i915_dri.so
b604e000-b6059000 rw-p b604e000 00:00 0
b6059000-b60e4000 r--p 00000000 08:08 1644585
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
b60e4000-b6142000 rw-p b60e4000 00:00 0
b6142000-b6148000 r--s 00000000 08:08 2035659
/var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2
b6148000-b614b000 r--s 00000000 08:08 2035673
/var/cache/fontconfig/e383d7ea5fbe662a33d9b44caf393297-x86.cache-2
b614b000-b614f000 r--s 00000000 08:08 2035656
/var/cache/fontconfig/921a30a17f0be15c70ac14043cb7a739-x86.cache-2
b614f000-b6150000 r--s 00000000 08:08 2035666
/var/cache/fontconfig/c69f04ab05004e31a6d5e715764f16d8-x86.cache-2
b6150000-b6151000 r--s 00000000 08:08 2035646
/var/cache/fontconfig/4c73fe0c47614734b17d736dbde7580a-x86.cache-2
b6151000-b6154000 r--s 00000000 08:08 2035661
/var/cache/fontconfig/a755afe4a08bf5b97852ceb7400b47bc-x86.cache-2
b6154000-b6155000 r--s 00000000 08:08 2035652
/var/cache/fontconfig/75a2cd575a62c63e802c11411fb87c37-x86.cache-2
b6155000-b6158000 r--s 00000000 08:08 2035650
/var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2
b6158000-b615a000 r--s 00000000 08:08 2035670
/var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-x86.cache-2
b615a000-b6162000 r--s 00000000 08:08 2035674
/var/cache/fontconfig/e3de0de479f42330eadf588a55fb5bf4-x86.cache-2
b6162000-b6168000 r--s 00000000 08:08 2035638
/var/cache/fontconfig/0f34bcd4b6ee430af32735b75db7f02b-x86.cache-2
b6168000-b6169000 r--s 00000000 08:08 2035644
/var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86.cache-2
b6169000-b616b000 r--s 00000000 08:08 2035671
/var/cache/fontconfig/de9486f0b47a4d768a594cb4198cb1c6-x86.cache-2
b616b000-b6171000 r--s 00000000 08:08 2035668
/var/cache/fontconfig/d52a8644073d54c13679302ca1180695-x86.cache-2
b6171000-b6175000 r--s 00000000 08:08 2035636
/var/cache/fontconfig/089dead882dea3570ffc31a9898cfb69-x86.cache-2
b6175000-b6177000 r--s 00000000 08:08 2037717
/var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2
b6177000-b6178000 r--s 00000000 08:08 2035678
/var/cache/fontconfig/fcff1cd55d48a2c86a175e9943c3506d-x86.cache-2
b6178000-b6179000 r--s 00000000 08:08 2035675
/var/cache/fontconfig/e9e44584608a73233979f764b5f9dd81-x86.cache-2
b6179000-b617a000 r--s 00000000 08:08 2035665
/var/cache/fontconfig/b8613a33de00eecd32d
Command terminated
__________________________________________________
This seems to be a fast method but my application crashes :-(

Regards
Bjorn Bergqvist
www.discretizer.org

From lyle.johnson at gmail.com  Tue Oct 23 19:12:58 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Tue, 23 Oct 2007 18:12:58 -0500
Subject: [fxruby-users] table.extractText problem
In-Reply-To: <44936e730710231303r1e51436m1f66d3940c682908@mail.gmail.com>
References: <44936e730710231303r1e51436m1f66d3940c682908@mail.gmail.com>
Message-ID: <4A9A6B71-7497-40DB-80BB-BB7A52066F4B@gmail.com>


On Oct 23, 2007, at 3:03 PM, Bj?rn Bergqvist wrote:

> I tried to use the FXTable::extractText like this
>
>      maxrow = MAX_ROW - 1
>       maxcol = MAX_COL - 1
>       printout = @table.extractText(0 , maxrow , 0 , maxcol ,  
> cs="\t", rs="\n")
>       #  Write the file
>       File.open(saveDialog.filename, "w").write(printout)
>
> then I got this output:

<snip>

Well, I don't know what the values of MAX_ROW and MAX_COL are (as  
compared to the table size), so I don't know if that's part of the  
problem or not. But I just make a quick modification to the standard  
table.rb example program to include a call to extractText():

     extract = FXMenuCommand.new(filemenu, "Extract text")
     extract.connect(SEL_COMMAND) do
       result = @table.extractText(0, @table.numRows - 1, 0,  
@table.numColumns - 1)
       puts result
     end

and this works as expected. Note that I used the default values for  
the last two arguments, but that shouldn't make a difference. If  
you're still having problems, please file a bug report and attach a  
short example program that demonstrates the problem.

Thanks,

Lyle

From bjorn.bergqvist at gmail.com  Wed Oct 24 11:25:23 2007
From: bjorn.bergqvist at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Bergqvist?=)
Date: Wed, 24 Oct 2007 17:25:23 +0200
Subject: [fxruby-users] table.extractText problem
In-Reply-To: <4A9A6B71-7497-40DB-80BB-BB7A52066F4B@gmail.com>
References: <44936e730710231303r1e51436m1f66d3940c682908@mail.gmail.com>
	<4A9A6B71-7497-40DB-80BB-BB7A52066F4B@gmail.com>
Message-ID: <44936e730710240825n56020b3dgc9f73011c398b0f0@mail.gmail.com>

Hello,
I did the modification and then I get:
*** glibc detected *** ruby: double free or corruption (!prev): 0x08260bb0 ***

Will file a bug report as soon as I find some time.

any value higher than: result = @table.extractText(0, 11, 0, 6)
will result in a crash like:
*** glibc detected *** ruby: malloc(): memory corruption: 0x08169000 ***
on my system. Maybe a gcc problem?

Regards
Bjorn Bergqvist
http://www.discretizer.org

2007/10/24, Lyle Johnson <lyle.johnson at gmail.com>:
>
> On Oct 23, 2007, at 3:03 PM, Bj?rn Bergqvist wrote:
>
> > I tried to use the FXTable::extractText like this
> >
> >      maxrow = MAX_ROW - 1
> >       maxcol = MAX_COL - 1
> >       printout = @table.extractText(0 , maxrow , 0 , maxcol ,
> > cs="\t", rs="\n")
> >       #  Write the file
> >       File.open(saveDialog.filename, "w").write(printout)
> >
> > then I got this output:
>
> <snip>
>
> Well, I don't know what the values of MAX_ROW and MAX_COL are (as
> compared to the table size), so I don't know if that's part of the
> problem or not. But I just make a quick modification to the standard
> table.rb example program to include a call to extractText():
>
>      extract = FXMenuCommand.new(filemenu, "Extract text")
>      extract.connect(SEL_COMMAND) do
>        result = @table.extractText(0, @table.numRows - 1, 0,
> @table.numColumns - 1)
>        puts result
>      end
>
> and this works as expected. Note that I used the default values for
> the last two arguments, but that shouldn't make a difference. If
> you're still having problems, please file a bug report and attach a
> short example program that demonstrates the problem.
>
> Thanks,
>
> Lyle
> _______________________________________________
> fxruby-users mailing list
> fxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/fxruby-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table.rb
Type: application/x-ruby
Size: 6992 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/fxruby-users/attachments/20071024/74e54baf/attachment-0001.bin 

From lyle.johnson at gmail.com  Wed Oct 24 11:55:49 2007
From: lyle.johnson at gmail.com (Lyle Johnson)
Date: Wed, 24 Oct 2007 10:55:49 -0500
Subject: [fxruby-users] table.extractText problem
In-Reply-To: <44936e730710240825n56020b3dgc9f73011c398b0f0@mail.gmail.com>
References: <44936e730710231303r1e51436m1f66d3940c682908@mail.gmail.com>
	<4A9A6B71-7497-40DB-80BB-BB7A52066F4B@gmail.com>
	<44936e730710240825n56020b3dgc9f73011c398b0f0@mail.gmail.com>
Message-ID: <BD2D3E0F-2AC6-42D0-902A-846893BD0D64@gmail.com>


On Oct 24, 2007, at 10:25 AM, Bj?rn Bergqvist wrote:

> I did the modification and then I get:
> *** glibc detected *** ruby: double free or corruption (!prev):  
> 0x08260bb0 ***
>
> Will file a bug report as soon as I find some time.
>
> any value higher than: result = @table.extractText(0, 11, 0, 6)
> will result in a crash like:
> *** glibc detected *** ruby: malloc(): memory corruption:  
> 0x08169000 ***
> on my system. Maybe a gcc problem?

Very strange indeed. There are a few differences in our environments:  
I'm running Mac OS X, with Ruby 1.8.6 patchlevel 0 (not p36). And my  
FXRuby is built against FOX 1.6.28, not FOX 1.6.25. I will try to  
check this out under Linux and see if I can reproduce it; if I can't,  
I'm not sure what I can do about it.