fxruby-users Mailing List for FXRuby (Page 34)
Status: Inactive
Brought to you by:
lyle
Menu
▾
▴
fxruby-users — General-purpose discussion list for FXRuby
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(75) |
Jul
(90) |
Aug
(61) |
Sep
(56) |
Oct
(56) |
Nov
(39) |
Dec
(83) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(56) |
Feb
(45) |
Mar
(61) |
Apr
(40) |
May
(95) |
Jun
(79) |
Jul
(63) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|
From: Aaron S. <aa...@sc...> - 2003-07-01 00:22:05
|
At 07:56 -0600 30 Jun 2003, Hans Fugal <ha...@fu...> wrote: > Is anyone working on a debian package of FXRuby? From the Debia WNPP > page it looks like there isn't. I'm writing a recipe/meal-planning I did some packages for work awhile ago, but I've been waiting for the fox packages to get recompiled with the current g++ (bugs 178546 and 197048) before really working on getting it into debian. The latest version I did packages for was 1.0.22 against a libfox1.0c102_1.0.40 that I did myself. They're available from by using the following apt sources: deb http://pug.qqx.org/debian unstable/i386/ deb http://pug.qqx.org/debian unstable/all/ deb-src http://pug.qqx.org/debian unstable/source/ -- Aaron Schrab aa...@sc... http://www.schrab.com/aaron/ |
|
From: Lyle J. <jl...@cf...> - 2003-06-30 14:34:35
|
Hans Fugal wrote: > Is anyone working on a debian package of FXRuby? From the Debia WNPP > page it looks like there isn't. I'm writing a recipe/meal-planning > program for my wife now using FXRuby, and discovered it is not packaged > for Debian. Not a problem, it works fine from source. I am also > discovering that Fox is a delightful toolkit, and FXRuby is well done. > > I am aspiring to become a debian developer, and would like to create > this package if nobody else is working on it already. Hans, this sounds wonderful. You might want to coordinate efforts with Mauricio Fernandez (batsman.geo AT yahoo.com), as I know he's done some Debian packages of FOX and FXRuby in the past. |
|
From: Hans F. <ha...@fu...> - 2003-06-30 13:58:54
|
Is anyone working on a debian package of FXRuby? From the Debia WNPP page it looks like there isn't. I'm writing a recipe/meal-planning program for my wife now using FXRuby, and discovered it is not packaged for Debian. Not a problem, it works fine from source. I am also discovering that Fox is a delightful toolkit, and FXRuby is well done. I am aspiring to become a debian developer, and would like to create this package if nobody else is working on it already. --=20 Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach --------------------------------------------------------------------- GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 |
|
From: Tom F. <tcf...@mt...> - 2003-06-28 17:04:49
|
I need to make a Windows program that batch processes audio files, after the user drags them from Explorer to the program's window. This works easily in Linux, I just accept "text/uri-list". I was trying to find the Windows equivalent, so I wrote some code to list the offered types, which also works great in Linux. But in Windows, when dragging files from Explorer, I don't even get a SEL_DND_MOTION. My code is attached. Is it possible to get dropped files in Windows, and if so, how? Thanks, -- Tom Felker <tcf...@mt...> |
|
From: <ly...@kn...> - 2003-06-27 02:57:46
|
On Thu, 26 Jun 2003 15:56:45 -0700 (PDT), John Reed <col...@ya...> wrote : > I have 2 classes in my Ruby file. The 1st one is derived from FXMainWindow, and displays database records. The 2nd one is derived from FXDialogBox, and is used for user entry. OK. > I want to add a 3rd class to enable the writing to an archive database, as well as the retrieval of archived data. All that I want the user to enter is a beginning and ending date in FXTextFields., and then the 1st class will be used to either show the archived records or the records to be archived. OK. > I know that I cant have another class that is derived from FXDialogBox, so Ive been searching for solutions and havent come up with any so far. If more details are needed, please let me know. Perhaps I'm misunderstanding, but why do you think that you cant have another class derived from FXDialogBox? |
|
From: John R. <col...@ya...> - 2003-06-26 22:56:46
|
I have 2 classes in my Ruby file. The 1st one is derived from FXMainWindow, and displays database records. The 2nd one is derived from FXDialogBox, and is used for user entry. I want to add a 3rd class to enable the writing to an archive database, as well as the retrieval of archived data. All that I want the user to enter is a beginning and ending date in FXTextFields., and then the 1st class will be used to either show the archived records or the records to be archived. I know that I cant have another class that is derived from FXDialogBox, so Ive been searching for solutions and havent come up with any so far. If more details are needed, please let me know. Thanks in advance, John Reed --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! |
|
From: Steve T. <STU...@MU...> - 2003-06-24 21:47:40
|
Thanks Lyle that works great!
> -----Original Message-----
> From: Lyle Johnson [mailto:jl...@cf...]
> Sent: Tuesday, June 24, 2003 1:44 PM
> To: Steve Tuckner
> Cc: fxr...@li...
> Subject: Re: [Fxruby-users] (no subject)
>
>
> Steve Tuckner wrote:
>
> > I am trying to do something simple (I think) but it is not
> working for
>
> > me. I when the button is pressed to put another button
> below the first
>
> > button and so on until the entire frame scrolls. Below is my code.
>
> Right after the line that constructs the new button:
>
> v = FXButton.new(@contentFrame, "Button #{i}")
>
> you want to first add a line to create (or "realize") the button:
>
> v.create
>
> and then tell the vertical frame to recalculate its layout:
>
> @contentFrame.recalc
>
> Hope this helps,
>
> Lyle
|
|
From: Lyle J. <jl...@cf...> - 2003-06-24 18:33:46
|
Steve Tuckner wrote:
> I am trying to do something simple (I think) but it is not working for
> me. I when the button is pressed to put another button below the first
> button and so on until the entire frame scrolls. Below is my code.
Right after the line that constructs the new button:
v = FXButton.new(@contentFrame, "Button #{i}")
you want to first add a line to create (or "realize") the button:
v.create
and then tell the vertical frame to recalculate its layout:
@contentFrame.recalc
Hope this helps,
Lyle
|
|
From: Steve T. <STU...@MU...> - 2003-06-24 18:23:21
|
Hello all,
I am trying to do something simple (I think) but it is not working for
me. I when the button is pressed to put another button below the first
button and so on until the entire frame scrolls. Below is my code.
Thanks for the help in advance
Steve Tuckner
------------------------------------------------------------------------
--------------------
require "fox"
include Fox
class FxTestWindow < FXMainWindow
def initialize(app)
# Invoke base class initialize first
super(app, "FxTest", nil, nil, DECOR_ALL, 0, 0, 600, 600)
scrollFrame = FXScrollWindow.new(self, LAYOUT_FILL_X|LAYOUT_FILL_Y)
@contentFrame = FXVerticalFrame.new(scrollFrame,
LAYOUT_FILL_X|LAYOUT_FILL_Y)
FXText.new(@contentFrame, nil, 0, LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT,
0, 0, 200, 100)
i = 1
FXButton.new(@contentFrame, "Add Control").connect(SEL_COMMAND) do
$stdout.print "button pressed\n"
$stdout.flush
v = FXButton.new(@contentFrame, "Button #{i}")
$stdout.print "v = #{v}\n"
$stdout.flush
i += 1
end
end
# Start
def create
super
show(PLACEMENT_SCREEN)
end
end
def runGUI
# Make an application
$application = FXApp.new("Dialog", "FxWorld")
# Open the display
$application.init(ARGV)
# Construct the application's main window
FxTestWindow.new($application)
# Create the application
$application.create
# Run the application
$application.run
end
runGUI
|
|
From: Lyle J. <ly...@us...> - 2003-06-19 18:34:21
|
Steve Tuckner wrote:
> In the past, there was a FXRuby example of how to do a scrollable frame
> where controls are added to it and it automatically scrolls to
> accomodate them. I can't find this email message however. Can someone
> point me to that example?
I don't know the specific example you're referring to, but you just want
to create an FXScrollWindow instance:
scrollWindow = FXScrollWindow.new(parent, ...)
and put a frame of some kind inside it:
contents = FXVerticalFrame.new(scrollWindow, ...)
and then add stuff to the frame:
FXButton.new(contents, ...)
Hope this helps,
Lyle
|
|
From: Lyle J. <jl...@cf...> - 2003-06-19 16:37:25
|
Joel VanderWerf wrote: > It might be confusing if > > btn.setTextColor(FXColor::Blue) > > returns btn, but > > btn.textColor = FXColor::Blue > > returns FXColor::Blue, which is the current behavior. True. > OTOH, the set* functions in the Fox C++ API consistently are declared to > return void, which is not an option in Ruby, so I guess Lyle is free to > return something that's more useful than nil. > > I kind of like the suggestion to return the receiver, so that you can > chain set* methods to operate on the same object. It gives the set* > methods a use that the corresponding attr_writers do not have, and makes > me feel better that they exist at all... For the time being I think I will leave it alone, but I have added a change request to the list at SourceForge. My gut reaction was that #setTextColor and #textColor= should have consistent return values, but I don't know that there's any precedent (e.g. in the standard Ruby library) that suggests this. So we may just get to make up our own rules for this one ;) |
|
From: Joel V. <vj...@PA...> - 2003-06-19 16:05:11
|
ly...@kn... wrote: ... >>However if you do: >> >> @foo = FXCheckButton.new(p3, 'Foo', >> nil,0).setTextColor(FXColor::Blue) >> >>@foo will be nil (but the color will be right) > > > It's not a bug, but if you think it's something we should consider changing, > I'm up for discussion. The effect of the second statement is that @foo gets > assigned the result of the call to FXCheckButton#setTextColor, and that > method currently returns nil. It might be confusing if btn.setTextColor(FXColor::Blue) returns btn, but btn.textColor = FXColor::Blue returns FXColor::Blue, which is the current behavior. OTOH, the set* functions in the Fox C++ API consistently are declared to return void, which is not an option in Ruby, so I guess Lyle is free to return something that's more useful than nil. I kind of like the suggestion to return the receiver, so that you can chain set* methods to operate on the same object. It gives the set* methods a use that the corresponding attr_writers do not have, and makes me feel better that they exist at all... |
|
From: <ly...@kn...> - 2003-06-19 15:21:01
|
On 19 Jun 2003 09:17:21 -0400, Bill Ramsay <Ra...@at...> wrote : > I think I've found a bug in FXRuby..... > > If you do this: > > @foo = FXCheckButton.new(p3, 'Foo', nil, 0) > @foo.setTextColor(FXColor::Blue) > > it will work. > > However if you do: > > @foo = FXCheckButton.new(p3, 'Foo', > nil,0).setTextColor(FXColor::Blue) > > @foo will be nil (but the color will be right) It's not a bug, but if you think it's something we should consider changing, I'm up for discussion. The effect of the second statement is that @foo gets assigned the result of the call to FXCheckButton#setTextColor, and that method currently returns nil. |
|
From: Dalibor S. <da...@in...> - 2003-06-19 08:21:16
|
> Your code is OK; I think this is a bug in FXRuby. As a workaround, > please see what happens if you replace this line: > > window.handle(window, > MKUINT(DbTalkWindow::ID_OPENCONNECTION, SEL_COMMAND), nil) > > with this: > > window.onOpenConnection(nil, nil, nil) > > If that takes care of it, I think I know what the problem is... Yes, the replacement works with no problem. Thanks, Dalibor Sramek |
|
From: Lyle J. <jl...@cf...> - 2003-06-18 15:57:33
|
Dalibor Sramek wrote: > I have the following code in my application (www.insula.cz/dbtalk/): > > # Handle interrupt to save stuff nicely > application.addSignal('SIGINT', window, DbTalkWindow::ID_QUIT) > > # Create the windows > application.create > > # Open the connection dialog automatically > window.handle(window, MKUINT(DbTalkWindow::ID_OPENCONNECTION, SEL_COMMAND), nil) > > # Start event loop > application.run > > > This worked perfectly in FXRuby 1.0.20 but it crashes in 1.0.24 on the line > with window.handle. It is used for automatical opening of a dialog window after > the application starts-up. > > Is this a possible bug or did I use the feature incorrectly all the time before? Your code is OK; I think this is a bug in FXRuby. As a workaround, please see what happens if you replace this line: window.handle(window, MKUINT(DbTalkWindow::ID_OPENCONNECTION, SEL_COMMAND), nil) with this: window.onOpenConnection(nil, nil, nil) If that takes care of it, I think I know what the problem is... Lyle |
|
From: Joel V. <vj...@PA...> - 2003-06-18 15:28:27
|
Lyle Johnson wrote: > FXGLViewer#create calls #setBounds, which in turn resets the model's > center to its original position (i.e. the center of the bounding box for > the model). So the effects of your call to FXGLViewer#translate are > wiped out before you get a chance to see them. Ah, that makes sense. Thanks. I'll put the call at the end of my scene-generating code. |
|
From: Lyle J. <jl...@cf...> - 2003-06-18 14:56:12
|
Joel VanderWerf wrote:
>> I want to change the viewer's position, and #translate is what seems
>> to do it in Fox. At least, that's how right-click-and-drag is
>> implemented. But calling translate thru the FXRuby interface doesn't
>> seem to have any effect. Anyone know how to do this?
>
>
> Just to be more precise, I applied the following patch to glviewer.rb.
> The zoom changes, but not the viewer position.
FXGLViewer#create calls #setBounds, which in turn resets the model's
center to its original position (i.e. the center of the bounding box for
the model). So the effects of your call to FXGLViewer#translate are
wiped out before you get a chance to see them.
Try moving the call to #translate to some point *after* the window has
been created. As a quick hack to the glviewer.rb example program, try
replacing one of the menu item's callbacks with a call to translate, e.g.
openCmd.connect(SEL_COMMAND) {
viewer.translate(FXVec.new(2, 2, 2))
}
If you want the model to start out "translated", I suppose you can also
subclass FXGLViewer and override its #create method.
Hope this helps,
Lyle
|
|
From: Dalibor S. <da...@in...> - 2003-06-17 08:55:05
|
I am sorry for the missing subject. I have put it in the Cc line mistakenly. :-( -- Dalibor Sramek http://www.insula.cz/dali | In the eyes of cats, dal...@in... | all things belong to cats. Quoting Dalibor Sramek <da...@in...>: > Hi. > > I have the following code in my application (www.insula.cz/dbtalk/): > > # Handle interrupt to save stuff nicely > application.addSignal('SIGINT', window, DbTalkWindow::ID_QUIT) > > # Create the windows > application.create > > # Open the connection dialog automatically > window.handle(window, MKUINT(DbTalkWindow::ID_OPENCONNECTION, SEL_COMMAND), > nil) > > # Start event loop > application.run > > > This worked perfectly in FXRuby 1.0.20 but it crashes in 1.0.24 on the line > with window.handle. It is used for automatical opening of a dialog window > after > the application starts-up. > > Is this a possible bug or did I use the feature incorrectly all the time > before? > > Thanks > > Dalibor Sramek > > -- > Dalibor Sramek http://www.insula.cz/dali | In the eyes of cats, > dal...@in... | all things belong to cats. |
|
From: Dalibor S. <da...@in...> - 2003-06-17 08:48:23
|
Hi. I have the following code in my application (www.insula.cz/dbtalk/): # Handle interrupt to save stuff nicely application.addSignal('SIGINT', window, DbTalkWindow::ID_QUIT) # Create the windows application.create # Open the connection dialog automatically window.handle(window, MKUINT(DbTalkWindow::ID_OPENCONNECTION, SEL_COMMAND), nil) # Start event loop application.run This worked perfectly in FXRuby 1.0.20 but it crashes in 1.0.24 on the line with window.handle. It is used for automatical opening of a dialog window after the application starts-up. Is this a possible bug or did I use the feature incorrectly all the time before? Thanks Dalibor Sramek -- Dalibor Sramek http://www.insula.cz/dali | In the eyes of cats, dal...@in... | all things belong to cats. |
|
From: Joel V. <vj...@PA...> - 2003-06-17 01:49:58
|
Joel VanderWerf wrote:
>
> I want to change the viewer's position, and #translate is what seems to
> do it in Fox. At least, that's how right-click-and-drag is implemented.
> But calling translate thru the FXRuby interface doesn't seem to have any
> effect. Anyone know how to do this?
Just to be more precise, I applied the following patch to glviewer.rb.
The zoom changes, but not the viewer position.
--- glviewer.rb 2003-06-11 14:28:34.000000000 -0700
+++ glviewer-test.rb 2003-06-16 18:47:03.000000000 -0700
@@ -254,6 +254,9 @@
viewer = FXGLViewer.new(mdichild, @glvisual, self, ID_GLVIEWER,
LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_TOP|LAYOUT_LEFT)
+ viewer.zoom = 2
+ viewer.translate FXVec.new(100,100,100)
+
# Tab book with switchable panels
panels = TabBook.new(frame, @mdiclient)
|
|
From: Joel V. <vj...@PA...> - 2003-06-16 23:54:41
|
I want to change the viewer's position, and #translate is what seems to do it in Fox. At least, that's how right-click-and-drag is implemented. But calling translate thru the FXRuby interface doesn't seem to have any effect. Anyone know how to do this? |
|
From: Hugh S. S. E. E. <hg...@dm...> - 2003-06-16 09:11:07
|
On Sat, 14 Jun 2003, Lyle Johnson wrote:
> If memory serves, Jeroen has added a clear() method for FXTextField in
> FOX 1.2, but you're correct that it's not there for FOX 1.0. You would
> just need to set the text field's text to the empty string, i.e.
>
> aTextField.text = ""
OK, that makes sense...
>
> OK, so focusing on the SEL_COMMAND handler block for @clear_button, I
> can see a few things that are definitely wrong. Back at the top of the
> LoginWindow#initialize method, you set @user as follows:
>
> @user = FXDataTarget.new("")
>
> and so @user holds a reference to a FXDataTarget instance. So far, so
> good. But the first line of the SEL_COMMAND handler for @clear_button is:
>
> @user = ""
>
> which constructs a new String, and assigns it to @user (this is just
DOH! Good point, I was forgetting this fundamental aspect of ruby!
<blush/>
[...]
> that data target object). The next line:
>
> @username.text = ""
>
> is a good guess, and I wish it would have worked (but I know why it
> doesn't). I'll come back to that in a moment. The next line:
>
> @username.handle(@clear_button, SEL_CHANGED, "")
>
> is also a good guess, but more complicated than you would want. If you
> did want to take this route, though, you'd need to fix the second
> argument to handle() so that it includes both the message type and
> message identifier, e.g.
Yes, I thought that was probably part of it, since the last
correpsondence...
>
> @username.handle(@clear_button, MKUINT(0, SEL_CHANGED), "")
Yes, I've seen things like this in the C++, but this reads to me
like "make an unsigned Int of (0,SEL_CHANGED)" so the "magic" must
lie in that first parameter? Would you have a ref to point me at
for this, please? I may not need the details now given the info
below, but it would be good to understand.
>
> But again, this looks ugly, and there's a better way.
>
> When you've attached a data target to one or more widgets and want to
> update the value of that data target programmatically (e.g. resetting
> the string to the empty string), you want to use the FXDataTarget#value
> accessor methods. So for your case, you should be able to write the
> SEL_COMMAND handler for @clear_button as follows:
>
> @clear_button.connect(SEL_COMMAND) {
> @user.value = ""
> @pass.value = ""
> }
That is a lot nicer. Thank you. And hence this is not .text
because it is not the GUI element that is being changed.
>
> Hope this helps,
>
> Lyle
>
>
Thank you,
Hugh
|
|
From: Lyle J. <ly...@kn...> - 2003-06-14 15:16:05
|
Hugh Sasse Staff Elec Eng wrote:
> Maybe this will help deepen my understanding. I'm building a front
> end to some "database", which is probably too grand a name for it.
> So I have a login window. I want to have a button to clear the text
> fields. I don't see a clear method for FXTextField, ...
If memory serves, Jeroen has added a clear() method for FXTextField in
FOX 1.2, but you're correct that it's not there for FOX 1.0. You would
just need to set the text field's text to the empty string, i.e.
aTextField.text = ""
> ... but then, I'm using a DataTarget, so that doesn't matter;
> the two are intimately connected, right? :-) The code below is where
I am now.
> Before adding the @username.handle() commands, the fields cleared on button
> realease, only to get immediately reset to the non-clear values they
> just had. Now I get a problem with
>
> FXRuby.cpp:781: FXASSERT(type!=SEL_NONE) failed.
> FXRuby.cpp:781: FXASSERT(type!=SEL_NONE) failed.
>
> so this suggests I have really munged the messages.
OK, so focusing on the SEL_COMMAND handler block for @clear_button, I
can see a few things that are definitely wrong. Back at the top of the
LoginWindow#initialize method, you set @user as follows:
@user = FXDataTarget.new("")
and so @user holds a reference to a FXDataTarget instance. So far, so
good. But the first line of the SEL_COMMAND handler for @clear_button is:
@user = ""
which constructs a new String, and assigns it to @user (this is just
standard Ruby assignment semantics). So that doesn't really have any
effect on anything (other than eliminating one of your references to
that data target object). The next line:
@username.text = ""
is a good guess, and I wish it would have worked (but I know why it
doesn't). I'll come back to that in a moment. The next line:
@username.handle(@clear_button, SEL_CHANGED, "")
is also a good guess, but more complicated than you would want. If you
did want to take this route, though, you'd need to fix the second
argument to handle() so that it includes both the message type and
message identifier, e.g.
@username.handle(@clear_button, MKUINT(0, SEL_CHANGED), "")
But again, this looks ugly, and there's a better way.
When you've attached a data target to one or more widgets and want to
update the value of that data target programmatically (e.g. resetting
the string to the empty string), you want to use the FXDataTarget#value
accessor methods. So for your case, you should be able to write the
SEL_COMMAND handler for @clear_button as follows:
@clear_button.connect(SEL_COMMAND) {
@user.value = ""
@pass.value = ""
}
Hope this helps,
Lyle
|
|
From: Lyle J. <jl...@cf...> - 2003-06-13 20:08:29
|
Hugh Sasse Staff Elec Eng wrote: > Would people coming to Ruby from FOX in C++ appreciate an alias for > this? (Not that I can remember if RDoc includes aliases in the > methods pane). Perhaps. I intentionally didn't try to document the getters and setters both ways (i.e. both as "attribute" accessors, as well as with the getXXX and setXXX methods) because, at the time, it seemed like overkill. But your point is well taken, that immigrants from the C++ FOX world may get testy if they believe we've done away with their setXXX() and getXXX() methods ;) |
|
From: Sander J. <sx...@cf...> - 2003-06-13 19:42:13
|
If you're table can have a unlimited size, putting objects in the table i= s=20 quit expensive. A better solution would be to make two icons: one checke= d,=20 one unchecked (or just one if the unchecked one is just empty). and catch= =20 messages from the table and based on if a cell needs to be checked or not= ,=20 set the appropiate icon for that cell. You could do something similar with a FXIconList. (which might even be a=20 better solution for your case) Sander On Friday 13 June 2003 02:35 pm, Frank Polscheit wrote: > Hi, > I am using a FXTable object and want to insert a check button as a new > cell. > How can I do this? Reading the API documentation and examples, I only > found > plain text and icons. Is it possible to put any object derived from > FXObject > into a cell and how are messages like mouse klick handled to react on > actions? > > Thank's in advance for any help, > Frank |
3 messages has been excluded from this view by a project administrator.
