fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] show(PLACEMENT_MAXIMIZED) > maximized?

[Rich <ri...@li...>]

I'm not seeing the method 'maximize' off of the FXMainWindow object.

There's a maximize for MDI stuff...

... I'm confused.

-Richard

----- Original Message ----- 
From: "jeroen" <je...@fo...>
To: <fxr...@li...>
Cc: "Joseph" <rub...@te...>
Sent: Tuesday, June 22, 2004 8:28 PM
Subject: Re: [Fxruby-users] show(PLACEMENT_MAXIMIZED) > maximized?


> On Tuesday 22 June 2004 07:39 pm, Joseph wrote:
> > Hi.
> >
> > If I use PLACEMENT_SCREEN as the argument for show and then click on the
> > window's maximize button, then I get a normal MS Windows maximized
> > window. But if I use PLACEMENT_MAXIMIZED instead, then the client area
> > of the window occupies the full screen (i.e. as though I was in a
> > full-screen mode), and the window's border (including the system menu
> > and the minimize, maximize/restore, and close button are hidden (i.e.
> > there is no screen real estate left to display them). Can I use some
> > other PLACEMENT_xxx constant to programmatically have the window start
> > up in the normal MS Windows maximized mode?
>
> The call:
>
> mainwindow->maximize()
>
> is supposed to do the job.  I found that calling setDecor(DECOR_NONE)
> prior to this call has the desired effect, but this may be window-manager
> dependent.
>
>
> Regards,
>
> Jeroen
>
>
> -- 
>
+---------------------------------------------------------------------------
-+
> | Copyright (C) 21:20 06/22/2004 Jeroen van der Zijp.   All Rights
Reserved. |
>
+---------------------------------------------------------------------------
-+
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users
>

Re: [Fxruby-users] show(PLACEMENT_MAXIMIZED) > maximized?

[jeroen <je...@fo...>]

On Tuesday 22 June 2004 07:39 pm, Joseph wrote:
> Hi.
>
> If I use PLACEMENT_SCREEN as the argument for show and then click on the
> window's maximize button, then I get a normal MS Windows maximized
> window. But if I use PLACEMENT_MAXIMIZED instead, then the client area
> of the window occupies the full screen (i.e. as though I was in a
> full-screen mode), and the window's border (including the system menu
> and the minimize, maximize/restore, and close button are hidden (i.e.
> there is no screen real estate left to display them). Can I use some
> other PLACEMENT_xxx constant to programmatically have the window start
> up in the normal MS Windows maximized mode?

The call:

	mainwindow->maximize()

is supposed to do the job.  I found that calling setDecor(DECOR_NONE)
prior to this call has the desired effect, but this may be window-manager
dependent.


Regards,

		Jeroen


-- 
+----------------------------------------------------------------------------+
| Copyright (C) 21:20 06/22/2004 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

[Fxruby-users] WorkAround :-)!

[Joseph <rub...@te...>]

Hi List.

I've found a work-around for my original problem. I was using the 
SEL_CONFIGURE event to be notified of modifications to the size of the 
window, so that I would be able to recalculate and reset the size of 
columns in an FXTable, based on the value of self.width (self here being 
the parent window, i.e. the main window). The default behavior of 
FXTable is to resize itself, but without resizing the columns. At the 
time the main window received the SEL_CONFIGURE notification, its width 
had not yet been set to the new size of the window.
I now discovered that if I hook into the FXTable SEL_CONFIGURE message 
instead of the main window's SEL_CONFIGURE, then, by the time the 
FXTable is notified, the self.width value of the parent window (i.e. the 
main window) has already been set to the new size. Perhaps somewhat 
coincidental, but it appears to work consistently.

One down, many more to go ....
Joseph

[Fxruby-users] show(PLACEMENT_MAXIMIZED) > maximized?

[Joseph <rub...@te...>]

Hi.

If I use PLACEMENT_SCREEN as the argument for show and then click on the 
window's maximize button, then I get a normal MS Windows maximized 
window. But if I use PLACEMENT_MAXIMIZED instead, then the client area 
of the window occupies the full screen (i.e. as though I was in a 
full-screen mode), and the window's border (including the system menu 
and the minimize, maximize/restore, and close button are hidden (i.e. 
there is no screen real estate left to display them). Can I use some 
other PLACEMENT_xxx constant to programmatically have the window start 
up in the normal MS Windows maximized mode?

TIA,
Joseph

[Fxruby-users] HowTo: Identify new size of window, after maximize / resize

[Joseph <rub...@te...>]

Hi List.

I have not been successful in identifying the new width of a window, 
after the window has been resized (more precisely: maximized or restored).
It appears that at the time the SEL_CONFIGURE event is sent to the main 
window, the main window's self.width property still contains the 
previous size. Thus, when the window is being maximized, self.width 
reports a smaller number, and when the window is being restored back to 
its original size, then self.width reports the higher number 
representing the width at the time window was still maximized. The 
<data|root|last>_x properties reported by FXEvent also report the (same) 
previous value.
Is this a bug or the intended behavior? Is there some way to retrieve 
the width (height) of the maximized window, when maximizing a window 
generates a SEL_CONFIGURE event?

TIA,
Joseph

Re: [Fxruby-users] Identifying Display Properties

[Sander J. <sa...@kn...>]

On Monday 21 June 2004 08:26 pm, Joseph wrote:
> Hi Mailinglist.
>
> 1. Under MS Windows, does FXRuby provide any way to identify the
> resolution of the current display (i.e. is the display running in
> 640x480 mode, or 800x600, 1024x768, 1280x1024, or whatever)?

The rootwindow has this kind of information (in C++):

	getApp()->getRootWindow()->getHeight();
	getApp()->getRootWindow()->getWidth();


> 2. The SEL_CONFIGURE event of an FXWindow object, sent when the window's
> size changes, is accompanied by an FXEvent. The FXevent includes entries
> for root_x and root_y, as well win_x and win_y. How do I tell the
> current width and height of the main window?


event.rect.x
event.rect.y
event.rect.z
event.rect..h


	Sander
>
> TIA,
> Joseph
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users

-- 
"Nervous hands grip tight the knife
In the darkness, till the cake is cut"
	- Peter Gabriel

[Fxruby-users] Identifying Display Properties

[Joseph <rub...@te...>]

Hi Mailinglist.

1. Under MS Windows, does FXRuby provide any way to identify the 
resolution of the current display (i.e. is the display running in 
640x480 mode, or 800x600, 1024x768, 1280x1024, or whatever)?
2. The SEL_CONFIGURE event of an FXWindow object, sent when the window's 
size changes, is accompanied by an FXEvent. The FXevent includes entries 
for root_x and root_y, as well win_x and win_y. How do I tell the 
current width and height of the main window?

TIA,
Joseph

Re: [Fxruby-users] Scintilla FXDataTarget Bug?

[jeroen <je...@fo...>]

On Wednesday 16 June 2004 09:04 pm, Joseph wrote:
> Hi.
>
> Jeroen, thanks for enlightening me (in more detail) to layout management
> and FXSplitter. It came in handy.
>
> A new problem:
> I was experimenting with FXDataTarget, FXText, and FXScintilla.  The
> FXScintilla widget does not appear to be working with FXDataTarget objects.
> In Detail (code follows below)
> I have a FXText widget, and a FXScintilla widget. Each is connected to
> its own FXDataTarget instance. I initialize the two FXDataTarget
> instances to a static value, and then implement a button handler that
> prints out the value of both FXDataTarget instances.
> 1. The static text assigned to the DataTarget associated with the FXText
> instance is displayed in the FXText widget, however, FXScintilla does
> not display the text assigned to the DataTarget associated with the
> FXScintilla widget.
> 2. If I type something into both the FXText widget, as well as the
> FXScintilla widget, then the DataTarget associated with the FXText now
> contains the text that was entered interactively, whereas the DataTarget
> prints the text that was originally assigned to the DataTarget
> programmatically. I.e. if I hit the "Print" button, then the new value
> is printed for the FXText DataTarget, but the Scintilla DataTarget does
> not print the modified contents that was typed into the Scintilla widget.


Of course, its up to FXScintilla to issue the messages [and handle the
ID_GETSTRINGVALUE messages] so that the datatarget system works.

However, for such large chunks of text as you can have in an editor it
is a bit of an expensive mechanism.

So I'd suggest to think twice about using it even if the FXScintilla
text component does implement it fully [unless of course you don't
expect a lot of text; with small bits of text it should not be a
problem].


Regards,

		Jeroen

-- 
+----------------------------------------------------------------------------+
| Copyright (C) 23:50 12/11/2003 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

Re: [Fxruby-users] FXFont initialization is complex

[Simon S. <ne...@ad...>]

On Thursday 17 June 2004 13:44, Lyle Johnson wrote:
> On Jun 17, 2004, at 4:52 AM, Lyle Johnson wrote:
> > On Jun 16, 2004, at 6:48 PM, Simon Strandgaard wrote:
> >> First I tried changing to a windows specific font
> >>
> >> @font = FXFont.new(application, 	"Fixedsys")
> >>
> >> But that segfaulted
> >
> > OK, I will try this out on Windows shortly...
>
> OK, Simon, I just ran a quick test under Windows and could not
> reproduce this one. I took the "mditest.rb" example program from the
> FXRuby examples directory, and changed this line:

The windows box is located at my friends place.. its xp.
I cannot remember the details about the setup..
I think he has used the one-click-installer..
I installed the newest version of fox+fxruby.. but it was the day before 
yesterday.. so I guess its 1.0.28 ?

Next time I visit him, I will try to make 'mditest.rb' fail, they same way.

>
> 	@font = FXFont.new(getApp(), "courier", 15, FONTWEIGHT_BOLD)
>
> to this:
>
> 	@font = FXFont.new(getApp(), "Fixedsys")
>
> This ran fine under Windows (and used the expected font). This was with
> the FXRuby-1.0.29 release from yesterday, under Ruby 1.8.1 on a Windows
> XP box.
>
> If you find the time, can you submit a bug report to the SourceForge
> page for FXRuby with a short example program that demonstrates the
> problem?

Time is not the problem. I run linux, I will have to visit my friend in order 
to reproduce the problem..  Then I will submit a bugreport..

I don't know when I visit my friend again.. so until then :-)

--
Simon Strandgaard

Re: [Fxruby-users] New tab item not visible via block

[Duane J. <dua...@gm...>]

I finally figured it out--I needed to 'create' the objects after
instantiating them.  I'm not sure why, but after 'create'ing,
'show'ing doesn't seem to be necessary.

Thanks for your help!  It got me started on the right track.

Duane Johnson

On Thu, 17 Jun 2004 12:42:16 -0600, Rich <ri...@li...> wrote:
> 
> Are you instantiating Objects without 'show'ing them?
> 
> Everything that is instantiated before the MainWindow is shown will be shown
> along with the MainWindow.
> 
> Anything else that is created while the application is running needs to be
> manually shown.
> 
> -Richard
> 
> 
> ----- Original Message -----
> From: "Duane Johnson" <dua...@gm...>
> To: <fxr...@li...>
> Sent: Thursday, June 17, 2004 11:42 AM
> Subject: [Fxruby-users] New tab item not visible via block
> 
> > I have an FXTabBook object to which I'm adding pairs of FXTabItem and
> > FXFrame.  This works perfectly until I try to add a pair from within a
> > menu item message block.  In other words, I want to be able to click
> > "New" in the file menu and have a new tab item with its contents
> > appear.  The trouble is that although the code is being executed, the
> > FXTabItem is not appearing.
> >
> > Here is the code (simplest case):
> >
> > <pre>
> > require 'fox'
> > require 'fox/colors'
> >
> > include Fox
> >
> > class PlayTextMainWindow < FXMainWindow
> > def initialize(app)
> > # Call the base class initialize() first
> > super(app, "PlayText", nil, nil, DECOR_ALL, 0, 0, 800, 600)
> >
> > # Menu bar, along the top
> > menubar = FXMenubar.new(self, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)
> >
> > # Separator
> > FXHorizontalSeparator.new(self,
> > LAYOUT_SIDE_TOP|LAYOUT_FILL_X|SEPARATOR_GROOVE)
> >
> > $editorTabs = FXTabBook.new( self, nil, 0,
> > LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_TOP)
> >
> > # NOTE: This call to addEditor WORKS
> > addEditor( "New" )
> >
> > # File menu
> > filemenu = FXMenuPane.new(self)
> > FXMenuCommand.new(filemenu, "&New\tCtl-N\tNew Text
> > Window.").connect(SEL_COMMAND) do
> > # NOTE: This call to addEditor is made, but a new tab DOES NOT appear!
> > addEditor( "test", "", true )
> > end
> > FXMenuCommand.new(filemenu, "&Quit\tCtl-Q\tQuit the application.", nil,
> >   getApp(), FXApp::ID_QUIT)
> > FXMenuTitle.new(menubar, "&File", nil, filemenu)
> > end
> >
> > def addEditor( title, filename="", focus=true )
> > ti = FXTabItem.new( $editorTabs, title, nil,
> > LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_LEFT )
> >
> > p title
> > # Play text window
> > frame = FXHorizontalFrame.new( $editorTabs,
> > LAYOUT_FILL_X|LAYOUT_FILL_Y|FRAME_LINE )
> > editor = FXText.new( frame, nil, 0,
> > TEXT_WORDWRAP|LAYOUT_FILL_X|LAYOUT_FILL_Y)
> > if( focus )
> > $currentTextWindow = editor
> > $currentTextWindow.setFocus()
> > end
> > end
> >
> > def create
> > super
> > show(PLACEMENT_SCREEN)
> > end
> > end
> >
> > if __FILE__ == $0
> > application = FXApp.new("PlayText", "(C)2004 Duane Johnson")
> > stw = PlayTextMainWindow.new( application )
> > stw.enable
> >
> > # NOTE: This call to addEditor WORKS
> > stw.addEditor( "duane", "", true )
> >
> > application.create
> > application.run
> > end
> > </pre>
> >
> > I'd love to have some ideas on where I can modify this.  Thanks!
> >
> > Duane Johnson
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> > _______________________________________________
> > Fxruby-users mailing list
> > Fxr...@li...
> > https://lists.sourceforge.net/lists/listinfo/fxruby-users
> >
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users
>

Re: [Fxruby-users] New tab item not visible via block

[Rich <ri...@li...>]

Are you instantiating Objects without 'show'ing them?

Everything that is instantiated before the MainWindow is shown will be shown
along with the MainWindow.

Anything else that is created while the application is running needs to be
manually shown.

-Richard

----- Original Message ----- 
From: "Duane Johnson" <dua...@gm...>
To: <fxr...@li...>
Sent: Thursday, June 17, 2004 11:42 AM
Subject: [Fxruby-users] New tab item not visible via block


> I have an FXTabBook object to which I'm adding pairs of FXTabItem and
> FXFrame.  This works perfectly until I try to add a pair from within a
> menu item message block.  In other words, I want to be able to click
> "New" in the file menu and have a new tab item with its contents
> appear.  The trouble is that although the code is being executed, the
> FXTabItem is not appearing.
>
> Here is the code (simplest case):
>
> <pre>
> require 'fox'
> require 'fox/colors'
>
> include Fox
>
> class PlayTextMainWindow < FXMainWindow
> def initialize(app)
> # Call the base class initialize() first
> super(app, "PlayText", nil, nil, DECOR_ALL, 0, 0, 800, 600)
>
> # Menu bar, along the top
> menubar = FXMenubar.new(self, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)
>
> # Separator
> FXHorizontalSeparator.new(self,
> LAYOUT_SIDE_TOP|LAYOUT_FILL_X|SEPARATOR_GROOVE)
>
> $editorTabs = FXTabBook.new( self, nil, 0,
> LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_TOP)
>
> # NOTE: This call to addEditor WORKS
> addEditor( "New" )
>
> # File menu
> filemenu = FXMenuPane.new(self)
> FXMenuCommand.new(filemenu, "&New\tCtl-N\tNew Text
> Window.").connect(SEL_COMMAND) do
> # NOTE: This call to addEditor is made, but a new tab DOES NOT appear!
> addEditor( "test", "", true )
> end
> FXMenuCommand.new(filemenu, "&Quit\tCtl-Q\tQuit the application.", nil,
>   getApp(), FXApp::ID_QUIT)
> FXMenuTitle.new(menubar, "&File", nil, filemenu)
> end
>
> def addEditor( title, filename="", focus=true )
> ti = FXTabItem.new( $editorTabs, title, nil,
> LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_LEFT )
>
> p title
> # Play text window
> frame = FXHorizontalFrame.new( $editorTabs,
> LAYOUT_FILL_X|LAYOUT_FILL_Y|FRAME_LINE )
> editor = FXText.new( frame, nil, 0,
> TEXT_WORDWRAP|LAYOUT_FILL_X|LAYOUT_FILL_Y)
> if( focus )
> $currentTextWindow = editor
> $currentTextWindow.setFocus()
> end
> end
>
> def create
> super
> show(PLACEMENT_SCREEN)
> end
> end
>
> if __FILE__ == $0
> application = FXApp.new("PlayText", "(C)2004 Duane Johnson")
> stw = PlayTextMainWindow.new( application )
> stw.enable
>
> # NOTE: This call to addEditor WORKS
> stw.addEditor( "duane", "", true )
>
> application.create
> application.run
> end
> </pre>
>
> I'd love to have some ideas on where I can modify this.  Thanks!
>
> Duane Johnson
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users
>

[Fxruby-users] New tab item not visible via block

[Duane J. <dua...@gm...>]

I have an FXTabBook object to which I'm adding pairs of FXTabItem and
FXFrame.  This works perfectly until I try to add a pair from within a
menu item message block.  In other words, I want to be able to click
"New" in the file menu and have a new tab item with its contents
appear.  The trouble is that although the code is being executed, the
FXTabItem is not appearing.

Here is the code (simplest case):

<pre>
require 'fox'
require 'fox/colors'

include Fox

class PlayTextMainWindow < FXMainWindow
	def initialize(app)
		# Call the base class initialize() first
		super(app, "PlayText", nil, nil, DECOR_ALL, 0, 0, 800, 600)

		# Menu bar, along the top
		menubar = FXMenubar.new(self, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)

		# Separator
		FXHorizontalSeparator.new(self,
			LAYOUT_SIDE_TOP|LAYOUT_FILL_X|SEPARATOR_GROOVE)

		$editorTabs = FXTabBook.new( self, nil, 0, 
			LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_TOP)
		
		# NOTE: This call to addEditor WORKS
		addEditor( "New" )

		# File menu
		filemenu = FXMenuPane.new(self)
		FXMenuCommand.new(filemenu, "&New\tCtl-N\tNew Text
Window.").connect(SEL_COMMAND) do
			# NOTE: This call to addEditor is made, but a new tab DOES NOT appear!
			addEditor( "test", "", true )
		end
		FXMenuCommand.new(filemenu, "&Quit\tCtl-Q\tQuit the application.", nil,
		  getApp(), FXApp::ID_QUIT)
		FXMenuTitle.new(menubar, "&File", nil, filemenu)
	end
		
	def addEditor( title, filename="", focus=true )
		ti = FXTabItem.new( $editorTabs, title, nil,
			LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_LEFT )

		p title
		# Play text window
		frame = FXHorizontalFrame.new( $editorTabs,
LAYOUT_FILL_X|LAYOUT_FILL_Y|FRAME_LINE )
		editor = FXText.new( frame, nil, 0,
			TEXT_WORDWRAP|LAYOUT_FILL_X|LAYOUT_FILL_Y)
		if( focus )
			$currentTextWindow = editor
			$currentTextWindow.setFocus()
		end
	end

	def create
		super
		show(PLACEMENT_SCREEN)
	end
end

if __FILE__ == $0
	application = FXApp.new("PlayText", "(C)2004 Duane Johnson")
	stw = PlayTextMainWindow.new( application )
	stw.enable
	
	# NOTE: This call to addEditor WORKS
	stw.addEditor( "duane", "", true )

	application.create
	application.run
end
</pre>

I'd love to have some ideas on where I can modify this.  Thanks!

Duane Johnson

Re: [Fxruby-users] FXFont initialization is complex

[Lyle J. <ly...@kn...>]

On Jun 17, 2004, at 4:52 AM, Lyle Johnson wrote:

> On Jun 16, 2004, at 6:48 PM, Simon Strandgaard wrote:
>
>> First I tried changing to a windows specific font
>>
>> @font = FXFont.new(application, 	"Fixedsys")
>>
>> But that segfaulted
>
> OK, I will try this out on Windows shortly...

OK, Simon, I just ran a quick test under Windows and could not 
reproduce this one. I took the "mditest.rb" example program from the 
FXRuby examples directory, and changed this line:

	@font = FXFont.new(getApp(), "courier", 15, FONTWEIGHT_BOLD)

to this:

	@font = FXFont.new(getApp(), "Fixedsys")

This ran fine under Windows (and used the expected font). This was with 
the FXRuby-1.0.29 release from yesterday, under Ruby 1.8.1 on a Windows 
XP box.

If you find the time, can you submit a bug report to the SourceForge 
page for FXRuby with a short example program that demonstrates the 
problem?

Thanks,

Lyle

Re: [Fxruby-users] Scintilla FXDataTarget Bug?

[Lyle J. <ly...@kn...>]

On Jun 16, 2004, at 9:04 PM, Joseph wrote:

> I was experimenting with FXDataTarget, FXText, and FXScintilla.  The 
> FXScintilla widget does not appear to be working with FXDataTarget 
> objects.

OK, after a quick scan of the FXScintilla source code it looks like 
you're right.

> Any ideas?

You can certainly file a change request with Gilles Filippini, the 
author of the FXScintilla widget, to get support for working with data 
targets. In the meantime, however, I think you're going to have to add 
a lot of "bootstrapping" code for this yourself. For example, when you 
modify the data target's value directly, you should make the 
corresponding change to the FXScintilla widget:

	@msgTarget.value = "foo"
	@sctl.setText(@msgTarget.value)

Similarly, you would need to catch the SEL_CHANGED message from 
FXScintilla to know when the user is changing things there, and then 
copy the new text into your string variable. Obviously, this is the 
kind of tedium that data target was invented to avoid, so if you can 
get Gilles to make that change it's all the better for all of us. ;)

Hope this helps,

Lyle

Re: [Fxruby-users] FXSplitter Question

[Lyle J. <ly...@kn...>]

On Jun 16, 2004, at 10:29 AM, Joseph wrote:

> Any ideas?

I'll assume that you've already read Jeroen's response to your  
question, in which he explained why the splitter doesn't know what  
initial sizes to assign to the two vertical frames inside it. I would  
also refer you to this article from the FOX Community Wiki Site:

	http://fox-toolkit.net/cgi-bin/wiki.pl?Cookbook/ 
Setting_The_Relative_Sizes_Of_Panes_In_An_FXSplitter

where one solution is described.

Hope this helps,

Lyle

Re: [Fxruby-users] FXFont initialization is complex

[Lyle J. <ly...@kn...>]

On Jun 16, 2004, at 6:48 PM, Simon Strandgaard wrote:

> First I tried changing to a windows specific font
>
> @font = FXFont.new(application, 	"Fixedsys")
>
> But that segfaulted

OK, I will try this out on Windows shortly. If I can reproduce it and 
it's a FOX bug, I'll need to forward this to Jeroen and see what can be 
done. If it's in the FXRuby layer, I will get it on our bug list and 
schedule it for the next release.

> <feature-request>
> I tried selecting a font via the fontselector.. but never managed to 
> get it
> working.  Better default-values would be nice.
> </feature-request>

Could you maybe submit a feature request to the project at SourceForge:

	http://sourceforge.net/tracker/?group_id=20243&atid=370243

and provide some more details about what might be appropriate default 
values?

> <feature-request>
> I tried add debug statements to the fxruby's sample editor, but had to
> write all fields manually that I wanted to see.  It would be nice if 
> #inspect
> was providing this information.
> </feature-request>

Yes, I agree. I've already added this feature request to the 
aforementioned list, but if you'd like to tack on some comments to that 
entry about a useful format, etc. please feel free.

> I spend 30 minutes attempting to change font.. but unsuccessfully.
> Please make font handling more robust, to avoid segfaults ;-)

Sorry about that. No one else has mentioned this to me in the last 
three years, and I didn't realize there was a problem. ;)

> Otherwise thanks Jeroen and Lyle for this great project.

... and thank you very much for taking time to report the problems and 
make suggestions.

[Fxruby-users] Scintilla FXDataTarget Bug?

[Joseph <rub...@te...>]

Hi.

Jeroen, thanks for enlightening me (in more detail) to layout management and FXSplitter. It came in handy.

A new problem:
I was experimenting with FXDataTarget, FXText, and FXScintilla.  The 
FXScintilla widget does not appear to be working with FXDataTarget objects.
In Detail (code follows below)
I have a FXText widget, and a FXScintilla widget. Each is connected to 
its own FXDataTarget instance. I initialize the two FXDataTarget 
instances to a static value, and then implement a button handler that 
prints out the value of both FXDataTarget instances.
1. The static text assigned to the DataTarget associated with the FXText 
instance is displayed in the FXText widget, however, FXScintilla does 
not display the text assigned to the DataTarget associated with the 
FXScintilla widget.
2. If I type something into both the FXText widget, as well as the 
FXScintilla widget, then the DataTarget associated with the FXText now 
contains the text that was entered interactively, whereas the DataTarget 
prints the text that was originally assigned to the DataTarget 
programmatically. I.e. if I hit the "Print" button, then the new value 
is printed for the FXText DataTarget, but the Scintilla DataTarget does 
not print the modified contents that was typed into the Scintilla widget.

Is FXScintilla forgetting to update the associated FXDataTarget 
instance? Here are the code snippets, plus results:

#>>>>>>>>>>>>>
    @textTarget = FXDataTarget.new("")
    @msgTarget = FXDataTarget.new("")

    @msgTarget.value = "static msgTest value"
    @textTarget.value = "static testTarget value"

    printButton = FXButton.new(buttons, "&Print")      
    printButton.connect(SEL_COMMAND)  do |sender, selector, data|
      print "@textTarget.value = [" + @textTarget.value + "]\n"
      print "@msgTarget.value = [" + @msgTarget.value  + "]\n"
    end       

    @tx = FXText.new(textframe, @textTarget, FXDataTarget::ID_VALUE,
       TEXT_WORDWRAP | LAYOUT_SIDE_TOP | LAYOUT_FILL_X | LAYOUT_FILL_Y)
    @sctl = FXScintilla.new(sctlframe, @msgTarget, FXDataTarget::ID_VALUE,
       LAYOUT_SIDE_TOP | LAYOUT_FILL_X | LAYOUT_FILL_Y) 
#<<<<<<<<<<<<<
@textTarget.value = [FXText test]
@msgTarget.value = [static msgTest value]

Any ideas?
TIA,
Joseph

Re: [Fxruby-users] FXSplitter Question

[jeroen <je...@fo...>]

On Wednesday 16 June 2004 10:29 am, Joseph wrote:
> Hi.
>
> I'm using a splitter to horizontally divide the main window into two
> horizontal areas, the top area, and the bottom area. The default
> behavior, i.e. before the user plays with the splitter, shall be that
> these two areas have the same height. However, I always get one area
> that occupies the full frame, and the other area is completely shrunk.
> If I use the SPLITTER_REVERSED option then the top area occupies the
> full frame, and if I omit this option, then the top area is invisible
> and the bottom area occupies the full frame. I've included the
> PACK_UNIFORM_HEIGHT option into the splitter, but that didn't make a
> difference either. To simplify the code, I've removed all content from
> the two area frames. The sample code I'm using:
>
>     @splitter = FXSplitter.new(self,
>      (LAYOUT_SIDE_TOP|LAYOUT_FILL_X|LAYOUT_FILL_Y | SPLITTER_VERTICAL|
>       SPLITTER_TRACKING|PACK_UNIFORM_HEIGHT))
>
>     area1 = FXVerticalFrame.new(@splitter, LAYOUT_SIDE_TOP|FRAME_THICK|
>          LAYOUT_FILL_X,0,0,0,0,0,0,0,0)
>
>     area2  = FXVerticalFrame.new(@splitter, LAYOUT_SIDE_TOP|FRAME_THICK|
>          LAYOUT_FILL_X| LAYOUT_FILL_Y,0,0,0,0,0,0,0,0)
> <<<<<<<<<<<<<<<<<
> I've tried using LAYOUT_SIDE_BOTTOM on both area1 and area1 instead of
> LAYOUT_SIDE_TOP, but that didn't appear to affect any modifications.
> Also, I tried leaving out LAYOUT_FILL_Y from the top frame, then I tried
> the same thing with the bottom frame, but modifying these options also
> did not produce the desired results.
>
> Any ideas?

What "holds the splitter up" is the child widgets.  Think mostly of "giftwrapping"
in the sense that the container widgets / layout managers normally shrink
around their content widgets. Thus, with no content, some of the container
widgets may become pretty small, unless you strut them up by internal padding
or plainly fixing the width/height.

In the case of FXSplitter, the size of the children can be set explicitly, and
the FXSplitter will keep those sizes as set until the user moves them.  The
exception is the last widget, which is stretched to fill the remaining space.
[In the case of SPLITTER_REVERSED that is the first widget].

One new twist that was added for 1.2 is that you can pass BOTH LAYOUT_FIX_WIDTH
and LAYOUT_FILL_X and this unique (and unnatural looking) combination will be
interpreted by FXSplitter to mean that the widget should not be smaller than
its minimum size.


Hope this helps,

	Regards,

			Jeroen


-- 
+----------------------------------------------------------------------------+
| Copyright (C) 23:50 12/11/2003 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+

[Fxruby-users] FXFont initialization is complex

[Simon S. <ne...@ad...>]

I went to my friends place and was hopeing to demonstrate my Aeditor GUI 
frontend to him.   He uses windows.. I use linux.

the #initialize method 

@font = FXFont.new(
	application, 
	"lucidatypewriter",
	24,
	FONTWEIGHT_BOLD,
	FONTSLANT_REGULAR,
	FONTENCODING_DEFAULT,
	FONTSETWIDTH_DONTCARE,
	FONTPITCH_FIXED
) 

the #create method

def create
	super
	@font.create
	@back_buffer.create
	@canvas.setFocus
	update_title 
end 


First I tried changing to a windows specific font

@font = FXFont.new(application, 	"Fixedsys")

But that segfaulted

<feature-request>
I tried selecting a font via the fontselector.. but never managed to get it 
working.  Better default-values would be nice.
</feature-request>

<feature-request>
I tried add debug statements to the fxruby's sample editor, but had to
write all fields manually that I wanted to see.  It would be nice if #inspect
was providing this information.
</feature-request>

I spend 30 minutes attempting to change font.. but unsuccessfully. 
Please make font handling more robust, to avoid segfaults ;-)


Otherwise thanks Jeroen and Lyle for this great project.

--
Simon Strandgaard

[Fxruby-users] FXSplitter Question

[Joseph <rub...@te...>]

Hi.

I'm using a splitter to horizontally divide the main window into two 
horizontal areas, the top area, and the bottom area. The default 
behavior, i.e. before the user plays with the splitter, shall be that 
these two areas have the same height. However, I always get one area 
that occupies the full frame, and the other area is completely shrunk. 
If I use the SPLITTER_REVERSED option then the top area occupies the 
full frame, and if I omit this option, then the top area is invisible 
and the bottom area occupies the full frame. I've included the 
PACK_UNIFORM_HEIGHT option into the splitter, but that didn't make a 
difference either. To simplify the code, I've removed all content from 
the two area frames. The sample code I'm using:
 >>>>>>>>>>>>>>>>>
    @splitter = FXSplitter.new(self,
     (LAYOUT_SIDE_TOP|LAYOUT_FILL_X|LAYOUT_FILL_Y | SPLITTER_VERTICAL|
      SPLITTER_TRACKING|PACK_UNIFORM_HEIGHT))

    area1 = FXVerticalFrame.new(@splitter, LAYOUT_SIDE_TOP|FRAME_THICK|
         LAYOUT_FILL_X,0,0,0,0,0,0,0,0)
  
    area2  = FXVerticalFrame.new(@splitter, LAYOUT_SIDE_TOP|FRAME_THICK|
         LAYOUT_FILL_X| LAYOUT_FILL_Y,0,0,0,0,0,0,0,0)
<<<<<<<<<<<<<<<<<
I've tried using LAYOUT_SIDE_BOTTOM on both area1 and area1 instead of 
LAYOUT_SIDE_TOP, but that didn't appear to affect any modifications. 
Also, I tried leaving out LAYOUT_FILL_Y from the top frame, then I tried 
the same thing with the bottom frame, but modifying these options also 
did not produce the desired results.

Any ideas?
TIA,
Joseph

[Fxruby-users] Re: [ANN] FXRuby-1.0.29 Now Available

[<ly...@kn...>]

On Wed, 16 Jun 2004 22:13:23 +0900, Rich <ri...@li...> wrote :

> I'm confused - this isn't the fxruby release that matches up with FOX 1.2 is
> it?
> 
> It's ok if it's not - I don't want to rush you... I'm just wondering if this
> is the one I need to get FOX 1.2 stuff...

No, but thanks for asking; I should have made that more clear. This is just
the latest release for the 1.0 branch, which was overdue for some bug fixes.

Things are progressing well on the 1.2 version, which I still hope to
release (at least in an "alpha" state) by the end of the month. All of the
"stuff" that was already present in FXRuby 1.0 has been updated for
compatibility with the FOX 1.2 API. What's left is to wrap all of the *new*
classes introduced in FOX 1.2 and make sure that they're basically working
properly.

In addition to this, I'm putting the finishing touches on the "What's New in
FOX 1.2" guide (see http://www.knology.net/~lyle/fox/1.2/WhatsNew.html for a
draft). While this is written in terms of the C++ API, it should prove
equally useful to FXRuby developers who are porting their FXRuby 1.0-based
applications to FXRuby 1.2.

[Fxruby-users] [ANN] FXRuby-1.0.29 Now Available

[Lyle J. <ly...@kn...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

FXRuby version 1.0.29 is now available for download from this page:

	http://sourceforge.net/project/showfiles.php?group_id=20243

The code is provided as both a Win32 installer, compatible with the 
latest Ruby 1.8.1 installer, or as a source tarball. For instructions 
on compiling FXRuby from source, please see:

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

For a summary of the changes in this release, please see this page:

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

As always, the FXRuby home page is here:

	http://www.fxruby.org

Enjoy,

Lyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD4DBQFA0D8aFXV/hD6oMd0RAmc8AJjLA5ui/TgbWATtgvv1ViDpsOGkAJsH0Juu
NjKe2UXxPeoEMxQGbN6prA==
=MJbN
-----END PGP SIGNATURE-----

[Fxruby-users] Re: Layout Manager questions in FxRuby

[Lyle J. <ly...@kn...>]

On Jun 15, 2004, at 8:29 PM, Lyle Johnson wrote:

>> 2.  The height of the window is appropriate when there are two 
>> buttons, but
>> not when there are three.  Why?
>
> Actually, the height of the window *is* appropriate when I run it here 
> on my Mac (i.e. under X11). I will have to see if I can reproduce your 
> problem under Windows and try to go from there.

OK, I tried it under Windows and I'm seeing the (different) behavior 
that you reported. Don't know why this doesn't work the same way, but I 
did find a workaround; just override your main window's create() method 
and add a line that tells the main window to resize itself to its 
preferred width and height, i.e.

	class TwoButtonUpdateWindow
		def create
			super
			resize(defaultWidth, defaultHeight)
		end
	end

This gives the desired result for both Windows and X11.

Hope this helps,

Lyle

[Fxruby-users] Re: Layout Manager questions in FxRuby

[Lyle J. <ly...@kn...>]

On Jun 15, 2004, at 10:28 AM, Richard Lionheart wrote:

> The attached program is an example I got from Hal Fulton's book,  or  
> rather,
> from his publisher's web site.  As the attached WordPad doc. shows with
> three images (resulting from running an enhanced version with optional
> arguments):
>
> 1.  The original program presents a window that displays two buttons  
> arrayed
> vertically.
> 2.  When an additional button is added,  however,  a narrower and  
> shorter
> window is presented.
> 3.  When the second window is expanded by dragging its border,  all  
> three
> buttons become fully visible.
>
> This raises the following questions.
>
> 1.  The default layout manager seems to be  FXVerticalFrame.  Is that  
> true?

You're adding the buttons directly as children of the FXMainWindow;  
FXMainWindow is just a subclass of FXTopWindow. According to this page  
from the FOX documentation:

	http://www.fox-toolkit.com/layout.html

the FXTopWindow "acts like an FXPacker window." I think that in your  
case it appears that it's using a vertical layout because the default  
layout hints for an FXButton are LAYOUT_SIDE_TOP and LAYOUT_SIDE_LEFT;  
in other words, unless you explicitly override those defaults, each new  
button will get "packed" to the top & left corner of the remaining  
space in the packer's cavity.

> 2.  The height of the window is appropriate when there are two  
> buttons, but
> not when there are three.  Why?

Actually, the height of the window *is* appropriate when I run it here  
on my Mac (i.e. under X11). I will have to see if I can reproduce your  
problem under Windows and try to go from there.

> 3.  The width of the window is dictated by width of the last button  
> added.
> True?

No, I'm pretty sure the width of the window is dictated by the width of  
the widest button.

> 4.  I found some good documentation on Layout Managers at
> http://www.eng.cse.dmu.ac.uk/~hgs/ruby/FXRuby/fox-1.0.40/doc/ 
> layout.html,
> but it didn't answer the foregoing questions. Is there other helpful  
> on-line
> documentation for layout managers?

No, not that I know of.

Re: [Fxruby-users] connect oddity?

[Joel V. <vj...@us...>]

Fredrik Jagenheim wrote:
> Hi,
> 
> I tried using connect like this:
> 
> 8<
> 
> j = 0
> 3.times { |i|
>   FXButton.new(self, "Button#{j}").connect(SEL_COMMAND) { 
>     puts "#{j} pressed"
>   }
>   j += 1
> }
> 
> 
>>8
> 
> 
> This doesn't work as intended, but if I use the 'i' variable, it does.
> I figured it had to do with global/local scope, but I don't grok it
> fully.

As you guessed, it's not particularly an effect of #connect. It has to
do with the way ruby associates bindings with code blocks. Your code
generates three closures (closure=code+binding) of the block

   {
     puts "#{j} pressed"
   }

and all three of them refer to the same j variable. The string isn't
interpolated until you execute the code. By the time the code executes
(when you press a button), the value of j is 3. So a "3" gets
interpolated in all three strings.

I didn't run the code (so I may be completely wrong ;) ), but I've been
bitten by this before.

Using just "i" instead of "j" is one way around, as you noticed. Another
way is to assign the value of j to a new local variable ("k", say)
inside the #times block, and use that in the string interpolation.

HTH.