Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

anthemion-devtools · Anthemion Tools for Developers

The Yahoo! Groups Product Blog

Check it out!

Group Information

? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 6314 - 6343 of 7465   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#6314 From: The Devils Jester <thedevilsjester@...>
Date: Sat Dec 12, 2009 6:20 pm
Subject: Re: Build Problem on Linux
akumanohoukon
Send Email Send Email
 
From what I can tell, the wxGLCanvas isn't properly initializing.
MyCanvas->GetContext() returns NULL and I am using the first creation
method described in this:

http://docs.wxwidgets.org/stable/wx_wxglcanvas.html

MyCanvas = new wxGLCanvas(canvas_backdrop, ID_GLCANVAS,
wxDefaultPosition, wxDefaultSize,  0, canvas_name, AttribList);

From what I gather GetContext() should return the context unless I use
the fourth creation method.  If there is no context, then SetCurrent()
wouldnt work, and that would cause problems with the first OpenGL
command I use.

This worked perfectly in wxWidgets 2.8.x does anyone have any ideas?

I realize that this now probably falls out of DBs scope as its
probably a wxWidgets issue...but any help would be appreciated.

On Sat, Dec 12, 2009 at 11:46 AM, Julian Smart <julian@...> wrote:
>
> The Devils Jester wrote:
>>
>>
>> GDB reports:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00767f66 in glEnable () from /usr/lib/libGL.so.1
>>
>> My non-DB non-wxWidgets component which uses OpenGL compiles and
>> executes perfectly.
>>
>> Is there any way to find out if this is a bug in wxWidgets, DB, or my
>> application?
> Just the usual stepping through the code to work out what's going on,
> I'm afraid.
>
> Regards,
>
> Julian
>
>>   My application doesnt even load (I have console output in the main
>> function and its never called).
>>
>>
>> On Sat, Dec 12, 2009 at 11:29 AM, The Devils Jester
>> <thedevilsjester@... <mailto:thedevilsjester@...>> wrote:
>>
>>     Does that new build simply remove the -arch flag?  I did that
>>     manually which is why I got the segfault.
>>
>>     I will try and compile wxWidgets 2.8.10 again if thats the case
>>     and get more details on its issues because 2.8.x doesnt segfault.
>>
>>
>>     On Sat, Dec 12, 2009 at 11:24 AM, Julian Smart
>>     <julian@... <mailto:julian@...>> wrote:
>>
>>
>>
>>         Hi,
>>
>>         Not sure about the segfault - you'll need to run the app under
>>         gdb to
>>         find out what the problem is - but the -arch is a DB bug, sorry.
>>
>>         Please try one these unofficial releases which should fix that:
>>
>>         Mac:
>>         http://www.dialogblocks.com/DialogBlocks-4.36.dmg
>>
>>         Linux:
>>         http://www.dialogblocks.com/DialogBlocks-4.36-i386.tar.gz
>>         http://www.dialogblocks.com/dialogblocks_4.36-1_i386.deb
>>         http://www.dialogblocks.com/dialogblocks-4.36-1.i386.rpm
>>
>>         Best regards,
>>
>>         Julian
>>
>>
>>
>>         The Devils Jester wrote:
>>         > A fresh install of Linux Mint 8, with only the normal build
>>         packages
>>         > installed, I have had numerous build problems.
>>         >
>>         > The first is (was) a build problem with wxWidgets through DB
>>         it failed
>>         > with some errors that research told me were fixed since
>>         2.8.10 was
>>         > released, so I compiled 2.9.0 instead (solved my issue there).
>>         >
>>         > After making the necessary changes to my application to
>>         compile in
>>         > 2.9.0, the compiler is yelling at me about some flags DB
>>         passes to it
>>         > (when compiling my app through DB, not compiling wxWidgets),
>>         namely
>>         > 'arch i386'
>>         >
>>         > This is the following error I get:
>>         >
>>         > *** g++: i386: No such file or directory
>>         > *** cc1plus: error: unrecognized command line option "-arch"
>>         >
>>         > If I manually edit the make file and remove the -arch option, it
>>         > compiles fine, but segfaults immediately when my app starts
>>         (before
>>         > any initialization).
>>         >
>>         > Does anyone have a clue as to why this is happening? Would
>>         removing
>>         > the -arch option cause a segfault or is it some 2.9.0 issue?
>>         If so,
>>         > is there a way I can still compile 2.8.10? I get errors
>>         about certain
>>         > wxWidgets defines not being set, and so and so already
>>         declared (I can
>>         > get more specific if this is my only option).
>>         >
>>         >
>>
>>         --
>>         Julian Smart, Anthemion Software Ltd.
>>         28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
>>         www.anthemion.co.uk <http://www.anthemion.co.uk> | +44 (0)131
>>         229 5306
>>         Tools for writers: www.writerscafe.co.uk
>>         <http://www.writerscafe.co.uk>
>>         wxWidgets RAD: www.dialogblocks.com <http://www.dialogblocks.com>
>>         Blog: www.juliansmart.com <http://www.juliansmart.com>
>>
>>
>>
>>
>>     --
>>     If you make something that any idiot can use, only idiots will use it.
>>
>>
>>
>>
>> --
>> If you make something that any idiot can use, only idiots will use it.
>>
>>
>>
>
>
> --
> Julian Smart, Anthemion Software Ltd.
> 28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
> www.anthemion.co.uk | +44 (0)131 229 5306
> Tools for writers: www.writerscafe.co.uk
> wxWidgets RAD:     www.dialogblocks.com
> Blog:              www.juliansmart.com
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



--
If you make something that any idiot can use, only idiots will use it.

#6315 From: Julian Smart <julian@...>
Date: Mon Dec 14, 2009 11:18 pm
Subject: ANN: DialogBlocks 4.36
felixcarswell
Send Email Send Email
 
Hi,

Just a few fixes this time.

Version 4.36, December 14th 2009

     * Corrected bug whereby setup wizard was never shown after first
DialogBlocks session.
     * -arch flags no longer written erroneously to non-Mac makefiles.
     * Eliminated spurious variable expansion warning when generating
makefiles.
     * No longer warns about the lack of a main window if using wxAppConsole.
     * Clarified prompt for WXWIN variable value.

Download from:
http://www.dialogblocks.com/download.htm

Regards,

Julian

--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD:     www.dialogblocks.com
Blog:              www.juliansmart.com

#6316 From: "AlexG" <alexgian@...>
Date: Wed Dec 23, 2009 1:24 am
Subject: Problem with wxEVT_COMMAND_TEXT_ENTER
alex_gian
Send Email Send Email
 
Hi - I've got a single line text control, and I want to trap the event when I
hit the enter button.

All the support code seems to have been generated OK by DB, for instance in the
event table I have:

     EVT_TEXT_ENTER( ID_TEXTCTRL, wxMyFrame::OnTextCommandEnter )

and the auto-generated function is much as you'd expect:

void wxMyFrame::OnTextCommandEnter( wxCommandEvent& event )
{
////@begin wxEVT_COMMAND_TEXT_ENTER event handler for ID_TEXTCTRL in wxMyFrame.
     // Before editing this code, remove the block markers.
     wxMessageBox(_("boo"));
////@end wxEVT_COMMAND_TEXT_ENTER event handler for ID_TEXTCTRL in wxMyFrame.
}

However, I get no response when I press [Enter] in the text widget; I just don't
think the event is going through.  Any ideas?
Incidentally, all my Menu events are working just fine.

System is a 64-bit Ubuntu Jaunty.

Thanks

#6317 From: "AlexG" <alexgian@...>
Date: Wed Dec 23, 2009 1:35 am
Subject: Problem with wxEVT_COMMAND_TEXT_ENTER
alex_gian
Send Email Send Email
 
Ignore my last question, I just found out I had to set the wxTE_PROCESS_ENTER
flag, too.

It's working fine now.

#6318 From: "Dave Silvia" <dsilvia@...>
Date: Wed Dec 23, 2009 6:16 pm
Subject: Re: Problem with wxEVT_COMMAND_TEXT_ENTER
ddotedotsdot
Send Email Send Email
 
Hi!

I hope you're not planning to leave your handler code inside the DB
generation markers.  If you do, DB will overwrite it...

FYI:

thx,
Dave S.

--------------------------------------------------
From: "AlexG" <alexgian@...>
Sent: Tuesday, December 22, 2009 7:24 PM
To: <anthemion-devtools@yahoogroups.com>
Subject: [anthemion-devtools] Problem with wxEVT_COMMAND_TEXT_ENTER

> Hi - I've got a single line text control, and I want to trap the event
> when I hit the enter button.
>
> All the support code seems to have been generated OK by DB, for instance
> in the event table I have:
>
>    EVT_TEXT_ENTER( ID_TEXTCTRL, wxMyFrame::OnTextCommandEnter )
>
> and the auto-generated function is much as you'd expect:
>
> void wxMyFrame::OnTextCommandEnter( wxCommandEvent& event )
> {
> ////@begin wxEVT_COMMAND_TEXT_ENTER event handler for ID_TEXTCTRL in
> wxMyFrame.
>    // Before editing this code, remove the block markers.
>    wxMessageBox(_("boo"));
> ////@end wxEVT_COMMAND_TEXT_ENTER event handler for ID_TEXTCTRL in
> wxMyFrame.
> }
>
> However, I get no response when I press [Enter] in the text widget; I just
> don't think the event is going through.  Any ideas?
> Incidentally, all my Menu events are working just fine.
>
> System is a 64-bit Ubuntu Jaunty.
>
> Thanks
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

#6319 From: Domingo Becker <domingobecker@...>
Date: Fri Jan 15, 2010 11:37 am
Subject: wxAppConsole support in DialogBlocks
domingobecker
Send Email Send Email
 
A minor issue: when I change wxApp to wxAppConsole, for some reason
there are two classes in the xxxapp.h file, one deriving from wxApp
and another derived from wxAppConsole.

The solution I found: Regenerate with overwrite.

DB 4.36 under Fedora 11 i386

kind regards

Domingo Becker

#6320 From: The Devils Jester <thedevilsjester@...>
Date: Sat Jan 16, 2010 3:43 pm
Subject: HelpBlocks saving issues
akumanohoukon
Send Email Send Email
 
I am having issues with HB not saving.  I open a file, paste some html
(or even some plain text) into it, hit save, click on another file and
then back to this one and its empty.  I try pasting it again making a
few modifications then saving, same result.  I write a little, save
it, it works.  I paste some into the already saved document, save it,
and its completely wiped again.

Sometimes it will save, and I will get code showing in RAW Html and
Preview modes, but there will be nothing in Edit mode.

Is there some trick I am missing?  I like the idea of HB, an html
editor designed around help file creation but this is turning into
more work than simply using gedit.

I am running Linux Mint 8 (Ubuntu 9.10 based) using HB 1.21

Also on a side note, when will replace all be completed?

--
If you make something that any idiot can use, only idiots will use it.

#6321 From: Julian Smart <julian@...>
Date: Sat Jan 16, 2010 6:27 pm
Subject: Re: HelpBlocks saving issues
felixcarswell
Send Email Send Email
 
Hi,

This sounds as though you are pasting text in a different encoding from
the one specified in Settings/Project/Edit Encodings/HTML encoding. Some
characters will cause the encoding conversion to fail and the file to
become empty.

Because the HTML source needs to be basically ASCII to pass through the
preprocessor used in HelpBlocks, HelpBlocks version 1.22 will convert
non-ASCII characters into HTML entities so the final ASCII HTML
requirement is not so onerous. I'll try to make a release of this
version a.s.a.p.

The Devils Jester wrote:
> I am having issues with HB not saving.  I open a file, paste some html
> (or even some plain text) into it, hit save, click on another file and
> then back to this one and its empty.  I try pasting it again making a
> few modifications then saving, same result.  I write a little, save
> it, it works.  I paste some into the already saved document, save it,
> and its completely wiped again.
>
> Sometimes it will save, and I will get code showing in RAW Html and
> Preview modes, but there will be nothing in Edit mode.
>
> Is there some trick I am missing?  I like the idea of HB, an html
> editor designed around help file creation but this is turning into
> more work than simply using gedit.
>
> I am running Linux Mint 8 (Ubuntu 9.10 based) using HB 1.21
>
> Also on a side note, when will replace all be completed?
>
I don't have a timescale for that I'm afraid.

Regards,

Julian

#6322 From: Domingo Becker <domingobecker@...>
Date: Thu Jan 21, 2010 12:47 pm
Subject: how to change the executable name
domingobecker
Send Email Send Email
 
I have made a project with a particular name.
The executable binary received its name.

But the project now perform 5 more similar tasks, and I want to change
the name of the binary because it's the one shown in nautilus' "open
with...", in order to make it clearer the tasks it does.

Is there a way to change the name of the binary in DB ?

DB 4.36, wxGTK2, Fedora 12.

kind regards

Domingo Becker

#6323 From: Julian Smart <julian@...>
Date: Thu Jan 21, 2010 1:25 pm
Subject: Re: how to change the executable name
felixcarswell
Send Email Send Email
 
Hi Domingo,

Changing "Executable name" in each configuration should do it.

Regards,

Julian

Domingo Becker wrote:
> I have made a project with a particular name.
> The executable binary received its name.
>
> But the project now perform 5 more similar tasks, and I want to change
> the name of the binary because it's the one shown in nautilus' "open
> with...", in order to make it clearer the tasks it does.
>
> Is there a way to change the name of the binary in DB ?
>
> DB 4.36, wxGTK2, Fedora 12.
>
> kind regards
>
> Domingo Becker
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>


--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD:     www.dialogblocks.com
Blog:              www.juliansmart.com

#6324 From: Domingo Becker <domingobecker@...>
Date: Thu Jan 21, 2010 3:50 pm
Subject: Re: how to change the executable name
domingobecker
Send Email Send Email
 
2010/1/21 Julian Smart <julian@...>
 

Hi Domingo,

Changing "Executable name" in each configuration should do it.


Thanks.
Too easy!
Sorry for the spam.  :-(

Regards

Domingo Becker


#6325 From: Lothar Behrens <lothar.behrens@...>
Date: Fri Jan 22, 2010 11:46 am
Subject: Sizerless dialogs and draggable controls?
lothar.behrens
Send Email Send Email
 
Hi,

my DialogBlocks is a registered version (4.2.6). Today I have checked
for new versions via the check for updates menu entry.
No updates were available to see if my 'missed' feature would be
available in a newer version.

I have tried adding controls (wxTextBox and label for sample) to a
panel without a sizer (removed the sizer).
It works to modify the properties X and Y and also width and hight. So
I am basically able to create custom
layouts like other non sizer based dialog editors.

But What I am missing is the ability to drag around the control or
resize it with the mouse.

Is this conceptually not possible or simply not planned to do so?

What I mean is this: If my software is used by a beginner who has no
experience with sizers, that user probably
wouldn't use DialogBlocks and I should plan to support an alternative
for my tool.

Currently I can create DialogBlocks projects from my tool (Database
application prototyper) to enable postproduction
to, say, fine tune the layout etc. My tool should make it simple for
the user to create database applications and thus
also database forms. But when he is unexperienced with sizers, then it
would be a problem in the workflow.

Also an idea is this: If a sizerless dialog (imported from any other
format) is importable, could it converted to a sizerbased version?

Thanks

Lothar

-- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
Lothar Behrens
Heinrich-Scheufelen-Platz 2
73252 Lenningen

#6326 From: Julian Smart <julian@...>
Date: Fri Jan 22, 2010 2:54 pm
Subject: Re: Sizerless dialogs and draggable controls?
felixcarswell
Send Email Send Email
 
Hi Lothar,

I'm afraid I haven't prioritized this functionality as adding it would
in some ways be worse than leaving it out, since it would encourage poor
layouts. Drag and drop support for wxGridBagLayout is the closest I've
got. I don't have absolute-positioning drag and drop support on my to-do
list.

I've always liked the idea of converting a sizerless dialog into a
sizer-based one but I could never figure out how to do it.

I wonder if for your app you could provide simplified layout whereby the
user specifies the size and the layout is done automatically, top-down.
Simplistic, but even easier than dragging and dropping. Perhaps too
basic though.

Regards,

Julian

Lothar Behrens wrote:
> Hi,
>
> my DialogBlocks is a registered version (4.2.6). Today I have checked
> for new versions via the check for updates menu entry.
> No updates were available to see if my 'missed' feature would be
> available in a newer version.
>
> I have tried adding controls (wxTextBox and label for sample) to a
> panel without a sizer (removed the sizer).
> It works to modify the properties X and Y and also width and hight. So
> I am basically able to create custom
> layouts like other non sizer based dialog editors.
>
> But What I am missing is the ability to drag around the control or
> resize it with the mouse.
>
> Is this conceptually not possible or simply not planned to do so?
>
> What I mean is this: If my software is used by a beginner who has no
> experience with sizers, that user probably
> wouldn't use DialogBlocks and I should plan to support an alternative
> for my tool.
>
> Currently I can create DialogBlocks projects from my tool (Database
> application prototyper) to enable postproduction
> to, say, fine tune the layout etc. My tool should make it simple for
> the user to create database applications and thus
> also database forms. But when he is unexperienced with sizers, then it
> would be a problem in the workflow.
>
> Also an idea is this: If a sizerless dialog (imported from any other
> format) is importable, could it converted to a sizerbased version?
>
> Thanks
>
> Lothar
>
> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
> Lothar Behrens
> Heinrich-Scheufelen-Platz 2
> 73252 Lenningen
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>


--
Julian Smart, Anthemion Software Ltd.
28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
www.anthemion.co.uk | +44 (0)131 229 5306
Tools for writers: www.writerscafe.co.uk
wxWidgets RAD:     www.dialogblocks.com
Blog:              www.juliansmart.com

#6327 From: "ggd_108" <ggdasa@...>
Date: Sun Jan 24, 2010 11:29 am
Subject: DialogBlocks vs. others?
ggd_108
Send Email Send Email
 
Hello!

I'll probably use wxhaskell as development tool my desktop GUI app (although I'd
still like to resolve some possible issues in regard to memory managament in
wxhaskell vs. gtk2hs) and since wxhaskell recently got support for dealing with
XRC files, I'm evaluating what would be appropriate tool for GUI design.

I've tried wxGlade, but it does not behave well with my desktop running xmonad
tiling WM.

wxDesigner does not look bad, costs more than DialogBlocks and I do not need
support for different code generation except XRC.

Moreover, by looking at the comparison table where wxSmith is compared with
other tools, it looks that DB supports more widgets.

This brings the list to practically two choices:

a) DialogBlocks and

b) wxFormBuilder


I've asked the similar question both on wxwidgets list as well as in wxFB
forums, but, except the info that DB & wxDesginer are the best supported, I
haven't got much info.

I'm aware it is also personal thing, but being a wxWidgets noob not being
familiar at all with the intricacies of developing for wx, I'd like to hear some
experience of the more advanced developers, on which feature to take a note when
evaluating and, finally, some of the pro/cons. which were deciding factors to
favor DB over the other tools?


Sincerely,
Gour

#6328 From: "Dave Silvia" <dsilvia@...>
Date: Mon Jan 25, 2010 2:19 pm
Subject: Re: DialogBlocks vs. others?
ddotedotsdot
Send Email Send Email
 
Hi!

I have tried about every IDE/RAD available for wxWidgets, free and
commercial.  I 'own' several commercial (including wxDesigner and
wxVisualSetup as well as DB).  I periodically check to see how the free
IDE/RAD tools are getting along.  None but DB is current, well supported,
and applies to more platforms and platform compilers/build-systems/tools.
It's practically impossible to beat.

> Moreover, by looking at the comparison table where wxSmith is compared
> with other tools, it looks that DB supports more widgets

If you're referring to the comparison table at wikipedia, it's tremendously
outdated.  DB supports almost all of the elements the table says it does
not.  One curious entry in that table is 'Non-sizer design'.  To me, that's
like saying, "I want to own a 4 wheel drive vehicle to drive to the
supermarket, but I don't want to use the 4 wheel drive, so I want it to
perform just like a 2 wheel drive...".  While a 4 wheel drive is capable of
being used as 2 wheel, expecting it to be exactly alike shows a bit of
naďveté.  The power of wxWidgets *is* its sizers.  I will allow that the
sizer concept is possibly (probably?) the most difficult concept to 'grok'
in wxWidgets, it requires one to abandon their "drag'n'drop" mindset.
Sizers not only promote the cross-platform advantage of wxWidgets, they also
make it easier to define an application which may or may not be stretched,
resized, and/or have platform elements (i.e., font type/size) modified by
the user and still have the appearance the designer/developer/implementer
intended.  I will also allow that some may call this a 'personal' pov.

My primary platform is Windows (not because I prefer it, but because it is
so pervasive on the market.  my personal preference has always been Unix and
its spin-offs).  I do my complete design and preliminary build work using DB
and Visual Studio projects (no other IDE/RAD addresses Visual Studio
projects, only nmake).  DB generates all the necessary wxWidgets code and
the build files (.sln and .vcproj) and uses the Visual Studio devenv for
building.  Once the design is 'gelled', I then do my test/hand-coding/debug
runs using Visual Studio which allows me to take advantage of Visual
Studio's Intellisense and GUI debugger, which is far superior to the 'free'
alternatives and allows more 'intimate' investigation and development.  When
done, I then go to other platforms, like, say, Ubuntu, using the same DB
project, and have DB generate the needed build file(s) (usually
makefile(s)).  The build usually comes off without a hitch (if there are
any, they are mostly minor examples of compiler differences of 'opinion' and
amount to warnings, rarely, if ever, errors).  When the app is run, since it
has been built with wxWidgets and DB is intimately familiar with the
toolkit, it looks like that platform's 'look alike' counterpart to the one I
developed on Windows.  This is to say, my design is still there, only the
platform look and feel has changed.

It sounds positively trite and commercial to say that this is due to 2
facts:

1)  DialogBlocks development is kept current with wxWidgets releases.

2)  DialogBlocks is authored, maintained, and supported by Julian Smart,
originator of wxWidgets and current wx-dev team member.

Still, it is nonetheless true.  Julian puts himself into DB and into its
support arm, anthemion-devtools group on Yahoo groups.

Another slightly misleading statement in the comparison, the General
information table, says DB is 'free trial'.  This is true, but not in the
traditional sense, i.e., it does not adhere to the 'traditional' types of
trial limitations for commercial software.  The trial is not 'crippleware',
in the classic sense, it does have limitations, but these pertain to the
number of elements (i.e., GUI elements) an application may have and, of
late, to greatly advanced features, the core and basic usability of the
package is not impaired in any way.  It has no artificial time limit,
dictating how long it must take you to evaluate.  It does not make any
demarcations in support for registered vs. evaluation users, anyone and
everyone may ask questions, request help, or report bugs at
anthemion-devtools equally.  Response time is practically immediate, within
1-3 days, however, my experience and observation has been, at most, hours,
and frequently minutes, a record often not met by most other software
products, free or commercial.  Plus, you do not get RTFM answers or 'canned'
responses from FAQ's and KB's (unless, and this is infrequent, from other
group members).  Julian gives personal and considered response to each
submittal.

If it sounds like I cannot say enough about DialogBlocks and wxWidgets,
that's true.  If it sounds like I'm a paid endorser or employee or have some
other affiliation, that's false.  I'm just another user, and have been for
quite some time since I first discovered wxWidgets and my subsequent
encounter with DialogBlocks and Julian Smart a few years back.  My
development of software would, at this stage, be lost without the two.

I hope this fulfills your request to "hear some experience of the more
advanced developers", although I balk at the term 'advanced' as being quite
relative!:-)

HTH:

thx,
Dave S.

wxMS_developers - development with wxWidgets on MS Windows
http://tech.groups.yahoo.com/group/wxMS_developers/

wxWidgets Code Exchange
http://www.wxcodex.net/


--------------------------------------------------
From: "ggd_108" <ggdasa@...>
Sent: Sunday, January 24, 2010 5:29 AM
To: <anthemion-devtools@yahoogroups.com>
Subject: [anthemion-devtools] DialogBlocks vs. others?

> Hello!
>
> I'll probably use wxhaskell as development tool my desktop GUI app
> (although I'd still like to resolve some possible issues in regard to
> memory managament in wxhaskell vs. gtk2hs) and since wxhaskell recently
> got support for dealing with XRC files, I'm evaluating what would be
> appropriate tool for GUI design.
>
> I've tried wxGlade, but it does not behave well with my desktop running
> xmonad tiling WM.
>
> wxDesigner does not look bad, costs more than DialogBlocks and I do not
> need support for different code generation except XRC.
>
> Moreover, by looking at the comparison table where wxSmith is compared
> with other tools, it looks that DB supports more widgets.
>
> This brings the list to practically two choices:
>
> a) DialogBlocks and
>
> b) wxFormBuilder
>
>
> I've asked the similar question both on wxwidgets list as well as in wxFB
> forums, but, except the info that DB & wxDesginer are the best supported,
> I haven't got much info.
>
> I'm aware it is also personal thing, but being a wxWidgets noob not being
> familiar at all with the intricacies of developing for wx, I'd like to
> hear some experience of the more advanced developers, on which feature to
> take a note when evaluating and, finally, some of the pro/cons. which were
> deciding factors to favor DB over the other tools?
>
>
> Sincerely,
> Gour
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

#6329 From: Gour <ggdasa@...>
Date: Mon Jan 25, 2010 3:30 pm
Subject: Re: DialogBlocks vs. others?
ggd_108
Send Email Send Email
 
On Mon, 25 Jan 2010 08:19:55 -0600
>>>>>> "Dave" == "Dave Silvia" <dsilvia@...> wrote:

Hi Dave,

Dave> I have tried about every IDE/RAD available for wxWidgets, free
Dave> and commercial.  I 'own' several commercial (including wxDesigner
Dave> and wxVisualSetup as well as DB).  I periodically check to see
Dave> how the free IDE/RAD tools are getting along.

OK.

Dave> If you're referring to the comparison table at wikipedia, it's
Dave> tremendously outdated.

I am thinking about
http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features
and there wxFormsBuilder scores pretty good in comparison, not to say
that it supports Contrib widgets which DB (probasbly) can't due to
licensing issues.

Dave> The power of wxWidgets *is* its sizers.  I will allow that the
Dave> sizer concept is possibly (probably?) the most difficult concept
Dave> to 'grok' in wxWidgets, it requires one to abandon their
Dave> "drag'n'drop" mindset. Sizers not only promote the
Dave> cross-platform advantage of wxWidgets, they also make it easier
Dave> to define an application which may or may not be stretched,
Dave> resized, and/or have platform elements (i.e., font type/size)
Dave> modified by the user and still have the appearance the
Dave> designer/developer/implementer intended.

Is it something similar to GTK's 'packing mechanism' ?

Dave> My primary platform is Windows (not because I prefer it, but
Dave> because it is so pervasive on the market.

[...]

I'll develop on Linux, care for Mac OS and use Haskell so those IDE
features in DB are not so important for me.

Dave> Another slightly misleading statement in the comparison, the
Dave> General information table, says DB is 'free trial'.  This is
Dave> true, but not in the traditional sense, i.e., it does not adhere
Dave> to the 'traditional' types of trial limitations for commercial
Dave> software.  The trial is not 'crippleware', in the classic sense,
Dave> it does have limitations, but these pertain to the number of
Dave> elements (i.e., GUI elements) an application may have and, of
Dave> late, to greatly advanced features, the core and basic usability
Dave> of the package is not impaired in any way.  It has no artificial
Dave> time limit, dictating how long it must take you to evaluate.  It
Dave> does not make any demarcations in support for registered vs.
Dave> evaluation users, anyone and everyone may ask questions, request
Dave> help, or report bugs at anthemion-devtools equally.  Response
Dave> time is practically immediate, within 1-3 days, however, my
Dave> experience and observation has been, at most, hours, and
Dave> frequently minutes, a record often not met by most other software
Dave> products, free or commercial.  Plus, you do not get RTFM answers
Dave> or 'canned' responses from FAQ's and KB's (unless, and this is
Dave> infrequent, from other group members).  Julian gives personal and
Dave> considered response to each submittal.

That's great to hear.

Based on that I quickly dismissed wxDesigner 'cause it looks that
'eval' version is crippled.

Otoh, wxGlade seems to be not actively developed...

Dave> I hope this fulfills your request to "hear some experience of the
Dave> more advanced developers", although I balk at the term 'advanced'
Dave> as being quite relative!:-)

Thanks a lot. Nice insight. I'm looking for more experiences,
especially someone who can throw some light on pro/cons for DB
vs. wxFB which is to me the only real competitor.


Sincerely,
Gour

--

Gour (Gmail)  | Hlapicina, Croatia  | GPG key: 9AA2B054
---------------------------------------------------------------------------

#6330 From: "Dave Silvia" <dsilvia@...>
Date: Mon Jan 25, 2010 6:20 pm
Subject: Re: DialogBlocks vs. others?
ddotedotsdot
Send Email Send Email
 
 
My mistake, thought it was wikipedia.  Nonetheless, what I said is correct, it is out of date by a long way!
 
 
> wxFormsBuilder scores pretty good in comparison, not to say
> that it supports Contrib widgets which DB (probasbly) can't due to
>
licensing issues.
 
There are no features there which are attributed to wxFormBuilder which are not also in DialogBlocks, with the exception of the contributors elements.  I'm not so sure this is due to legal issues as much as it is due to what is/is not part of wxWidgets.  Contributors is not maintained and many pieces do not work.  It is, I believe, on the road to being deprecated as not an integral part of wxWidgets, but rather 'contributor' software, which should have it's own separate location with suitable monitors/mediators/maintainers.  It is, after all, a bit beyond the scope of any package to try to maintain any and all non-official pieces of code that exist.  If someone wishes to contribute to wxWidgets, there are formal ways to do this and the contribution is incorporated into the distribution proper.

Here's my take on wxFormBuilder.  The last stable release is almost 2 years old.  There is a more current 'beta' release that is only a month old, but it is more of a bug fix and minor feature effort.  There is no real significant change to the basic operation.  While wxFormBuilder is quite pleasing to the eye, it has many essential features missing, such as:
 
1)  Integrated Help
 
2)  User Preferences
 
3)  Overall Application Architecture support
 
4)  Basic Feature Relation Coherency
 
It also operates on the same misconception of most other IDE/RAD packages, that the 'best' way to approach a wxWidgets IDE/RAD is the old 'tried and true' drag'n'drop paradigm of early GUI packages, i.e., Visual Studio et al.  In doing so, no doubt to look familiar to users, it defeats one of the major strengths of wxWidgets; sizers.  Although not a complete impossibility to make a drag'n'drop wxWidgets IDE/RAD, the effort of the (true) logic is great and of doubtful use, so, what's the point?
 
Admittedly, in the 'beta' version, wxFormBuilder has attempted to correct some of these 'oversights' regarding drag'n'drop vs. sizers by adding error popups when one tries to add a feature that should (most of the time) have a sizer, but that's after the fact.  It's an attempt to save the original design paradigm, with its misconceptions, in spite of the inherent errors.  Also, there are instances where it 'insists' on a sizer where none is required.  E.G., the case of a child wxPanel for a wxFrame.  When there is only one child, and a background panel is a valid application of this, a sizer is superfluous.  This background grows and shrinks with the frame.  Similarly, any single child of a wxFrame does not need a sizer.  It is an integral part of the frame itself, and so, grows and shrinks with it; e.g., wxScrolledWindow, wxSplitterWindow, wxNotebook, etc..
 
This says that wxFormBuilder suffers from the same misbegotten ideas as do most all of the free IDE/RAD packages.  That the drag'n'drop paradigm must be preserved and that sizers are an added, but non-essential part of wxWidgets.  True, you can construct a wxWidgets application with nary a sizer, but that does not prove the point.  If you don't want sizers, use a different toolkit (don't try to make a 4 wheel drive into a 2 wheel drive!Winking smile emoticon).  The point which is proved is that the implementers of these IDE/RAD packages do not really understand what sizers are and how they work in wxWidgets.  It's very difficult to divorce one's self from old practices, of which drag'n'drop design is a prime example, but sometimes difficulties must be faced, not glossed over.  I know whereof I speak, as I was in their camp for a long time before I realized it was my mindset that was at fault, not wxWidgets and how a wxWidgets IDE/RAD should be implemented.  One could suppose that insiders to the wxWidgets design philosophy, like Robert Roebling and Julian Smart, just don't know how to do drag'n'drop.  It wouldn't be a strange conclusion to which to 'jump'.  I made such a conclusion 'jump'...  Then I talked a bit with Julian about sizers and thought a bit more about "now how would I do a sizers drag'n'drop that was effective and useful?" and came to the conclusion that the way they were doing it made much more sense, functionally, and was more effective and useful.  Can be a bitter pill to swallow...  Once swallowed, however, sizers become less of a mystery and design in wxWidgets is greatly simplified.
 
wxFormBuilder is riddled with inappropriate and misconceived presentations of how to enter data into a design engine to create a wxWidgets application.  It also creates somewhat obtuse, although valid, wxWidgets code.
 
These 'attributes' of wxFormBuilder are true of Code::Blocks, wxDev-C++, and others.  I think the upshot is, these are folks too far out on the periphery of wxWidgets who want to provide themselves and others with a wxWidgets development interface that fits what they are used to seeing.  Quite understandable and not really a fault, per se.  But sometimes, what we want, what will work, and what is functionally efficient and true to the design of the underlying pieces, are 3 distinct and different things.  This is one of those times.
 
As I said, I have used about every IDE/RAD available in wxWidgets, and my preference for DialogBlocks is thought out and founded.
 
 
> Dave> My primary platform is Windows (not because I prefer it, but
> Dave> because it is so pervasive on the market.
>
> [...] 
>
> I'll develop on Linux, care for Mac OS and use Haskell so those IDE
> features in DB are not so important for me. 

I believe you missed something in the '[...]' portion you elided.  The point was not Windows, or even Visual Studio, specific.  The point was that DB is intimately familiar with all platforms and build systems it addresses, and it addresses more than just wxWidgets distribution build systems, so that you may build on any system with whichever tools you desire that best suits your design/development needs and DB will take the finished product and allow you to build it on other systems transparently!Winking smile emoticon  This is the value impact I wished to impart, not the virtues of Window or Visual Studio, which I actually feel are quite parochial and limited!  I could just as well build with my favorite tools on Ubuntu (and have), then move to other systems, like Windows, and have DB generate the appropriate build files without changes to code or special #ifdef's for different platforms as that would be taken care of by the underlying wxWidgets cross-platform capability.  All code I design in DB is designated "<Any platform>", so my code is not cluttered with platform peculiarities, something none of the other IDE/RAD tools do.
 
Bottom line is maturity.  wxWidgets is considered a mature GUI toolkit.  DialogBlocks is equally considered a mature IDE/RAD tool for wxWidgets.  DB has paid its dues over the years in user base and attention paid to user needs and general (i.e., obvious) basic functionality in any IDE/RAD tool or Editor.  Much of this is behind the scenes functionality.  So it is understandable when a user opens, say, Code::Blocks, wxFormBuilder, and DialogBlocks, the flashier 'first blush' appearance of one tool compared to another can be enticing and promise great things.  But in the end, it's which one does the most for the least amount of effort on the part of the user that is really the value!Winking smile emoticon  DialogBlocks may not look as impressive as other 'eye candy' interfaces, but it's not just a façade, it's true design/development power!Winking smile emoticon
 
You might like to have a look at a basic presentation of a simple, fundamental tutorial for a wxWidgets application in DialogBlocks.  Might I suggest?
 
A Simple Editor: Sizers Tutorial - Navigable HTML Files in 7z archive
 
OR
 
A Simple Editor: Sizers Tutorial - Navigable HTML Files in Zip archive
 
at:
 
 
Not only will you get a basic hands-on experience with wxWidgets sizers, but you'll also see, incidentally, how a DialogBlocks wxWidgets application is instantiated.  Walk through it in DB, takes less than half an hour.  It will give you a pretty good handle on wxWidgets and DB.  A place to start working from and to develop new questions from.
 
I would then suggest trying to do the same in wxFormBuilder.  It's a bit more problematic and 'logical' procedural steps in building an application are not provided.  You have to know what you want and what comes next ahead of time in the context of wxWidgets, wxFormBuilder will offer no paths (it basically implies that any wxWidgets element may exist anywhere in any application, which is, of course, not true!).  I'm not saying it cannot be done with wxFormBuilder, or Code::Blocks or others, just that it's easier and requires less 'technical' input on the user's part in DB.
 
HTH:
 
thx,
Dave S.
 
wxMS_developers - development with wxWidgets on MS Windows
http://tech.groups.yahoo.com/group/wxMS_developers/
 
wxWidgets Code Exchange
http://www.wxcodex.net/





--------------------------------------------------
From: "Gour" <ggdasa@...>
Sent: Monday, January 25, 2010 9:30 AM
To: <anthemion-devtools@yahoogroups.com>
Subject: Re: [anthemion-devtools] DialogBlocks vs. others?
On Mon, 25 Jan 2010 08:19:55 -0600
>>>>>> "Dave" == "Dave Silvia" <dsilvia@...> wrote:

Hi Dave,

Dave> I have tried about every IDE/RAD available for wxWidgets, free
Dave> and commercial.  I 'own' several commercial (including wxDesigner
Dave> and wxVisualSetup as well as DB).  I periodically check to see
Dave> how the free IDE/RAD tools are getting along. 

OK.

Dave> If you're referring to the comparison table at wikipedia, it's
Dave> tremendously outdated. 

I am thinking about
http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features
and there wxFormsBuilder scores pretty good in comparison, not to say
that it supports Contrib widgets which DB (probasbly) can't due to
licensing issues.

Dave> The power of wxWidgets *is* its sizers.  I will allow that the
Dave> sizer concept is possibly (probably?) the most difficult concept
Dave> to 'grok' in wxWidgets, it requires one to abandon their
Dave> "drag'n'drop" mindset. Sizers not only promote the
Dave> cross-platform advantage of wxWidgets, they also make it easier
Dave> to define an application which may or may not be stretched,
Dave> resized, and/or have platform elements (i.e., font type/size)
Dave> modified by the user and still have the appearance the
Dave> designer/developer/implementer intended.

Is it something similar to GTK's 'packing mechanism' ?

Dave> My primary platform is Windows (not because I prefer it, but
Dave> because it is so pervasive on the market. 

[...]

I'll develop on Linux, care for Mac OS and use Haskell so those IDE
features in DB are not so important for me.

Dave> Another slightly misleading statement in the comparison, the
Dave> General information table, says DB is 'free trial'.  This is
Dave> true, but not in the traditional sense, i.e., it does not adhere
Dave> to the 'traditional' types of trial limitations for commercial
Dave> software.  The trial is not 'crippleware', in the classic sense,
Dave> it does have limitations, but these pertain to the number of
Dave> elements (i.e., GUI elements) an application may have and, of
Dave> late, to greatly advanced features, the core and basic usability
Dave> of the package is not impaired in any way.  It has no artificial
Dave> time limit, dictating how long it must take you to evaluate.  It
Dave> does not make any demarcations in support for registered vs.
Dave> evaluation users, anyone and everyone may ask questions, request
Dave> help, or report bugs at anthemion-devtools equally.  Response
Dave> time is practically immediate, within 1-3 days, however, my
Dave> experience and observation has been, at most, hours, and
Dave> frequently minutes, a record often not met by most other software
Dave> products, free or commercial.  Plus, you do not get RTFM answers
Dave> or 'canned' responses from FAQ's and KB's (unless, and this is
Dave> infrequent, from other group members).  Julian gives personal and
Dave> considered response to each submittal.

That's great to hear.

Based on that I quickly dismissed wxDesigner 'cause it looks that
'eval' version is crippled.

Otoh, wxGlade seems to be not actively developed...

Dave> I hope this fulfills your request to "hear some experience of the
Dave> more advanced developers", although I balk at the term 'advanced'
Dave> as being quite relative!:-)

Thanks a lot. Nice insight. I'm looking for more experiences,
especially someone who can throw some light on pro/cons for DB
vs. wxFB which is to me the only real competitor.


Sincerely,
Gour

--

Gour (Gmail)  | Hlapicina, Croatia  | GPG key: 9AA2B054
---------------------------------------------------------------------------


#6331 From: The Devils Jester <thedevilsjester@...>
Date: Mon Jan 25, 2010 8:49 pm
Subject: Re: DialogBlocks vs. others?
akumanohoukon
Send Email Send Email
 
I come from a Visual Basic/Windows background, and when I moved to Linux and started developing with wxWidgets I was stuck in the mind frame of static size and positioning like Visual Basic.  I found a couple wxWidgets GUI applications that allowed me to do this, but I never really enjoyed them.  I stopped using wxWidgets and moved to FOX for awhile, did some development in it, got used to the sizer concept, and when I moved back to wxWidgets (native themes ftw), I tried a few of those GUI building applications that I used before, and they just were not very intuitive.  Once I got used to the sizer concept, DialogBlocks was the only GUI/RAD/IDE that just made sense. 

Julian has always answered my questions quickly, and responded to issues, bug reports and feature requests in a very timely fashion.  I prefer DB over every application that I have tried, and I recommend it to anyone that is looking to get into wxWidgets.

Just my personal opinion.


On Mon, Jan 25, 2010 at 12:20 PM, Dave Silvia <dsilvia@...> wrote:
 

 
My mistake, thought it was wikipedia.  Nonetheless, what I said is correct, it is out of date by a long way!
 
 
> wxFormsBuilder scores pretty good in comparison, not to say
> that it supports Contrib widgets which DB (probasbly) can't due to
>
licensing issues.
 
There are no features there which are attributed to wxFormBuilder which are not also in DialogBlocks, with the exception of the contributors elements.  I'm not so sure this is due to legal issues as much as it is due to what is/is not part of wxWidgets.  Contributors is not maintained and many pieces do not work.  It is, I believe, on the road to being deprecated as not an integral part of wxWidgets, but rather 'contributor' software, which should have it's own separate location with suitable monitors/mediators/maintainers.  It is, after all, a bit beyond the scope of any package to try to maintain any and all non-official pieces of code that exist.  If someone wishes to contribute to wxWidgets, there are formal ways to do this and the contribution is incorporated into the distribution proper.

Here's my take on wxFormBuilder.  The last stable release is almost 2 years old.  There is a more current 'beta' release that is only a month old, but it is more of a bug fix and minor feature effort.  There is no real significant change to the basic operation.  While wxFormBuilder is quite pleasing to the eye, it has many essential features missing, such as:
 
1)  Integrated Help
 
2)  User Preferences
 
3)  Overall Application Architecture support
 
4)  Basic Feature Relation Coherency
 
It also operates on the same misconception of most other IDE/RAD packages, that the 'best' way to approach a wxWidgets IDE/RAD is the old 'tried and true' drag'n'drop paradigm of early GUI packages, i.e., Visual Studio et al.  In doing so, no doubt to look familiar to users, it defeats one of the major strengths of wxWidgets; sizers.  Although not a complete impossibility to make a drag'n'drop wxWidgets IDE/RAD, the effort of the (true) logic is great and of doubtful use, so, what's the point?
 
Admittedly, in the 'beta' version, wxFormBuilder has attempted to correct some of these 'oversights' regarding drag'n'drop vs. sizers by adding error popups when one tries to add a feature that should (most of the time) have a sizer, but that's after the fact.  It's an attempt to save the original design paradigm, with its misconceptions, in spite of the inherent errors.  Also, there are instances where it 'insists' on a sizer where none is required.  E.G., the case of a child wxPanel for a wxFrame.  When there is only one child, and a background panel is a valid application of this, a sizer is superfluous.  This background grows and shrinks with the frame.  Similarly, any single child of a wxFrame does not need a sizer.  It is an integral part of the frame itself, and so, grows and shrinks with it; e.g., wxScrolledWindow, wxSplitterWindow, wxNotebook, etc..
 
This says that wxFormBuilder suffers from the same misbegotten ideas as do most all of the free IDE/RAD packages.  That the drag'n'drop paradigm must be preserved and that sizers are an added, but non-essential part of wxWidgets.  True, you can construct a wxWidgets application with nary a sizer, but that does not prove the point.  If you don't want sizers, use a different toolkit (don't try to make a 4 wheel drive into a 2 wheel drive!Winking smile emoticon).  The point which is proved is that the implementers of these IDE/RAD packages do not really understand what sizers are and how they work in wxWidgets.  It's very difficult to divorce one's self from old practices, of which drag'n'drop design is a prime example, but sometimes difficulties must be faced, not glossed over.  I know whereof I speak, as I was in their camp for a long time before I realized it was my mindset that was at fault, not wxWidgets and how a wxWidgets IDE/RAD should be implemented.  One could suppose that insiders to the wxWidgets design philosophy, like Robert Roebling and Julian Smart, just don't know how to do drag'n'drop.  It wouldn't be a strange conclusion to which to 'jump'.  I made such a conclusion 'jump'...  Then I talked a bit with Julian about sizers and thought a bit more about "now how would I do a sizers drag'n'drop that was effective and useful?" and came to the conclusion that the way they were doing it made much more sense, functionally, and was more effective and useful.  Can be a bitter pill to swallow...  Once swallowed, however, sizers become less of a mystery and design in wxWidgets is greatly simplified.
 
wxFormBuilder is riddled with inappropriate and misconceived presentations of how to enter data into a design engine to create a wxWidgets application.  It also creates somewhat obtuse, although valid, wxWidgets code.
 
These 'attributes' of wxFormBuilder are true of Code::Blocks, wxDev-C++, and others.  I think the upshot is, these are folks too far out on the periphery of wxWidgets who want to provide themselves and others with a wxWidgets development interface that fits what they are used to seeing.  Quite understandable and not really a fault, per se.  But sometimes, what we want, what will work, and what is functionally efficient and true to the design of the underlying pieces, are 3 distinct and different things.  This is one of those times.
 
As I said, I have used about every IDE/RAD available in wxWidgets, and my preference for DialogBlocks is thought out and founded.
 
 
> Dave> My primary platform is Windows (not because I prefer it, but
> Dave> because it is so pervasive on the market.
>
> [...] 
>
> I'll develop on Linux, care for Mac OS and use Haskell so those IDE
> features in DB are not so important for me. 

I believe you missed something in the '[...]' portion you elided.  The point was not Windows, or even Visual Studio, specific.  The point was that DB is intimately familiar with all platforms and build systems it addresses, and it addresses more than just wxWidgets distribution build systems, so that you may build on any system with whichever tools you desire that best suits your design/development needs and DB will take the finished product and allow you to build it on other systems transparently!Winking smile emoticon  This is the value impact I wished to impart, not the virtues of Window or Visual Studio, which I actually feel are quite parochial and limited!  I could just as well build with my favorite tools on Ubuntu (and have), then move to other systems, like Windows, and have DB generate the appropriate build files without changes to code or special #ifdef's for different platforms as that would be taken care of by the underlying wxWidgets cross-platform capability.  All code I design in DB is designated "<Any platform>", so my code is not cluttered with platform peculiarities, something none of the other IDE/RAD tools do.
 
Bottom line is maturity.  wxWidgets is considered a mature GUI toolkit.  DialogBlocks is equally considered a mature IDE/RAD tool for wxWidgets.  DB has paid its dues over the years in user base and attention paid to user needs and general (i.e., obvious) basic functionality in any IDE/RAD tool or Editor.  Much of this is behind the scenes functionality.  So it is understandable when a user opens, say, Code::Blocks, wxFormBuilder, and DialogBlocks, the flashier 'first blush' appearance of one tool compared to another can be enticing and promise great things.  But in the end, it's which one does the most for the least amount of effort on the part of the user that is really the value!Winking smile emoticon  DialogBlocks may not look as impressive as other 'eye candy' interfaces, but it's not just a façade, it's true design/development power!Winking smile emoticon
 
You might like to have a look at a basic presentation of a simple, fundamental tutorial for a wxWidgets application in DialogBlocks.  Might I suggest?
 
A Simple Editor: Sizers Tutorial - Navigable HTML Files in 7z archive
 
OR
 
A Simple Editor: Sizers Tutorial - Navigable HTML Files in Zip archive
 
at:
 
 
Not only will you get a basic hands-on experience with wxWidgets sizers, but you'll also see, incidentally, how a DialogBlocks wxWidgets application is instantiated.  Walk through it in DB, takes less than half an hour.  It will give you a pretty good handle on wxWidgets and DB.  A place to start working from and to develop new questions from.
 
I would then suggest trying to do the same in wxFormBuilder.  It's a bit more problematic and 'logical' procedural steps in building an application are not provided.  You have to know what you want and what comes next ahead of time in the context of wxWidgets, wxFormBuilder will offer no paths (it basically implies that any wxWidgets element may exist anywhere in any application, which is, of course, not true!).  I'm not saying it cannot be done with wxFormBuilder, or Code::Blocks or others, just that it's easier and requires less 'technical' input on the user's part in DB.
 
HTH:
 
thx,
Dave S.
 
wxMS_developers - development with wxWidgets on MS Windows
http://tech.groups.yahoo.com/group/wxMS_developers/
 
wxWidgets Code Exchange
http://www.wxcodex.net/





--------------------------------------------------
From: "Gour" <ggdasa@...>
Sent: Monday, January 25, 2010 9:30 AMSubject: Re: [anthemion-devtools] DialogBlocks vs. others?

On Mon, 25 Jan 2010 08:19:55 -0600
>>>>>> "Dave" == "Dave Silvia" <dsilvia@...> wrote:

Hi Dave,

Dave> I have tried about every IDE/RAD available for wxWidgets, free
Dave> and commercial.  I 'own' several commercial (including wxDesigner
Dave> and wxVisualSetup as well as DB).  I periodically check to see
Dave> how the free IDE/RAD tools are getting along. 

OK.

Dave> If you're referring to the comparison table at wikipedia, it's
Dave> tremendously outdated. 

I am thinking about
http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features
and there wxFormsBuilder scores pretty good in comparison, not to say
that it supports Contrib widgets which DB (probasbly) can't due to
licensing issues.

Dave> The power of wxWidgets *is* its sizers.  I will allow that the
Dave> sizer concept is possibly (probably?) the most difficult concept
Dave> to 'grok' in wxWidgets, it requires one to abandon their
Dave> "drag'n'drop" mindset. Sizers not only promote the
Dave> cross-platform advantage of wxWidgets, they also make it easier
Dave> to define an application which may or may not be stretched,
Dave> resized, and/or have platform elements (i.e., font type/size)
Dave> modified by the user and still have the appearance the
Dave> designer/developer/implementer intended.

Is it something similar to GTK's 'packing mechanism' ?

Dave> My primary platform is Windows (not because I prefer it, but
Dave> because it is so pervasive on the market. 

[...]

I'll develop on Linux, care for Mac OS and use Haskell so those IDE
features in DB are not so important for me.

Dave> Another slightly misleading statement in the comparison, the
Dave> General information table, says DB is 'free trial'.  This is
Dave> true, but not in the traditional sense, i.e., it does not adhere
Dave> to the 'traditional' types of trial limitations for commercial
Dave> software.  The trial is not 'crippleware', in the classic sense,
Dave> it does have limitations, but these pertain to the number of
Dave> elements (i.e., GUI elements) an application may have and, of
Dave> late, to greatly advanced features, the core and basic usability
Dave> of the package is not impaired in any way.  It has no artificial
Dave> time limit, dictating how long it must take you to evaluate.  It
Dave> does not make any demarcations in support for registered vs.
Dave> evaluation users, anyone and everyone may ask questions, request
Dave> help, or report bugs at anthemion-devtools equally.  Response
Dave> time is practically immediate, within 1-3 days, however, my
Dave> experience and observation has been, at most, hours, and
Dave> frequently minutes, a record often not met by most other software
Dave> products, free or commercial.  Plus, you do not get RTFM answers
Dave> or 'canned' responses from FAQ's and KB's (unless, and this is
Dave> infrequent, from other group members).  Julian gives personal and
Dave> considered response to each submittal.

That's great to hear.

Based on that I quickly dismissed wxDesigner 'cause it looks that
'eval' version is crippled.

Otoh, wxGlade seems to be not actively developed...

Dave> I hope this fulfills your request to "hear some experience of the
Dave> more advanced developers", although I balk at the term 'advanced'
Dave> as being quite relative!:-)

Thanks a lot. Nice insight. I'm looking for more experiences,
especially someone who can throw some light on pro/cons for DB
vs. wxFB which is to me the only real competitor.


Sincerely,
Gour

--

Gour (Gmail)  | Hlapicina, Croatia  | GPG key: 9AA2B054
---------------------------------------------------------------------------




--
If you make something that any idiot can use, only idiots will use it.

#6332 From: Gour <ggdasa@...>
Date: Mon Jan 25, 2010 9:58 pm
Subject: Re: DialogBlocks vs. others?
ggd_108
Send Email Send Email
 
On Mon, 25 Jan 2010 12:20:39 -0600
>>>>>> "Dave" == "Dave Silvia" <dsilvia@...> wrote:

Dave> My mistake, thought it was wikipedia.  Nonetheless, what I said
Dave> is correct, it is out of date by a long way!

Really? It's from last June/July - now it shows today as last
update. :)

Dave> There are no features there which are attributed to wxFormBuilder
Dave> which are not also in DialogBlocks, with the exception of the
Dave> contributors elements.  I'm not so sure this is due to legal
Dave> issues as much as it is due to what is/is not part of wxWidgets.
Dave> Contributors is not maintained and many pieces do not work.  It
Dave> is, I believe, on the road to being deprecated as not an integral
Dave> part of wxWidgets, but rather 'contributor' software, which
Dave> should have it's own separate location with suitable
Dave> monitors/mediators/maintainers.  It is, after all, a bit beyond
Dave> the scope of any package to try to maintain any and all
Dave> non-official pieces of code that exist.  If someone wishes to
Dave> contribute to wxWidgets, there are formal ways to do this and the
Dave> contribution is incorporated into the distribution proper.

Hmm, this sounds logical and, otoh, I doubt that any 'contrib' widget
is bound in wxhaskell.

Dave> Here's my take on wxFormBuilder.  The last stable release is
Dave> almost 2 years old.  There is a more current 'beta' release that
Dave> is only a month old, but it is more of a bug fix and minor
Dave> feature effort.

Hmm, I've installed latest beta which is supposed to turn into 3.2.

Moreover, today I was shown some new stuff like: wxTreebook, wxWizard
and some wxAUI stuff.

Dave> While wxFormBuilder is quite pleasing to the eye, it has many
Dave> essential features missing, such as:

Dave> 1)  Integrated Help

OK.

Dave> 2)  User Preferences

OK.

Dave> 3)  Overall Application Architecture support

I'm not sure how this is relavant for my case when developing in
Haskell.

Dave> 4)  Basic Feature Relation Coherency

This is intriguing...


Dave> It also operates on the same misconception of most other IDE/RAD
Dave> packages, that the 'best' way to approach a wxWidgets IDE/RAD is
Dave> the old 'tried and true' drag'n'drop paradigm of early GUI
Dave> packages, i.e., Visual Studio et al.  In doing so, no doubt to
Dave> look familiar to users, it defeats one of the major strengths of
Dave> wxWidgets; sizers.  Although not a complete impossibility to make
Dave> a drag'n'drop wxWidgets IDE/RAD, the effort of the (true) logic
Dave> is great and of doubtful use, so, what's the point?

But the above-mentioned table says that wxFB is sizer-based and that
there is no support for non-sizer design, similar to DB and
wxDesigner?


Dave> Admittedly, in the 'beta' version, wxFormBuilder has attempted to
Dave> correct some of these 'oversights' regarding drag'n'drop vs.
Dave> sizers by adding error popups when one tries to add a feature
Dave> that should (most of the time) have a sizer, but that's after the
Dave> fact.  It's an attempt to save the original design paradigm, with
Dave> its misconceptions, in spite of the inherent errors.

Dave> Also, there are instances where it 'insists' on a sizer where
Dave> none is required.  E.G., the case of a child wxPanel for a
Dave> wxFrame.  When there is only one child, and a background panel
Dave> is a valid application of this, a sizer is superfluous.  This
Dave> background grows and shrinks with the frame.  Similarly, any
Dave> single child of a wxFrame does not need a sizer.  It is an
Dave> integral part of the frame itself, and so, grows and shrinks
Dave> with it; e.g., wxScrolledWindow, wxSplitterWindow, wxNotebook,
Dave> etc..

Huh, it seems that it lacks some 'intelligence' about the way
wxWidgets works.

Dave> Once swallowed, however, sizers become less of a mystery and
Dave> design in wxWidgets is greatly simplified.

Sizers resemble packing in GTK?

Dave> wxFormBuilder is riddled with inappropriate and misconceived
Dave> presentations of how to enter data into a design engine to create
Dave> a wxWidgets application.  It also creates somewhat obtuse,
Dave> although valid, wxWidgets code.

I'd have to play a bit with wXFB...

Dave> As I said, I have used about every IDE/RAD available in
Dave> wxWidgets, and my preference for DialogBlocks is thought out and
Dave> founded.

I can see that you're speaking based on your own experience.

Dave> I believe you missed something in the '[...]' portion you
Dave> elided.  The point was not Windows, or even Visual Studio,
Dave> specific.  The point was that DB is intimately familiar with all
Dave> platforms and build systems it addresses, and it addresses more
Dave> than just wxWidgets distribution build systems, so that you may
Dave> build on any system with whichever tools you desire that best
Dave> suits your design/development needs and DB will take the finished
Dave> product and allow you to build it on other systems
Dave> transparently!

Hmm, I'm not sure this is true for my case. There is no support in DB
to create Haskell source code, nor I envision I can add e.g GHC
compiler as my 'preferred' tool.

Moreover, when working with wxhaskell, one needs DB-like tool just to
create XRC file which is then loaded into Haskell source - similar to
GTK's mechanism of loading glade/gtkbuilder xml files.

Here is simple example:

-- Menu from XRC demo
module Main where

import Graphics.UI.WXCore
import Graphics.UI.WX

main = start gui

gui :: IO ()
gui =
     do
       f <- frameLoadRes "xrcmenu.xrc" "menuTest" []

       -- Attach event handlers to the menu items loaded above.
       menuItemOnCommandRes f "new" (onFileNew f)
       menuItemOnCommandRes f "open" (onFileOpen f)

       set f [clientSize := sz 400 300]
       windowShow f
       return ()

onFileNew w =
     do
       dlg <- dialog w [text := "File New"]
       ok  <- button dlg [text := "Ok"]
       _   <- showModal dlg (\onPress -> set ok [on command := onPress Nothing])
       return ()

onFileOpen w ="
     do
       dlg <- dialog w [text := "File Open"]
       ok  <- button dlg [text := "Ok"]
       _   <- showModal dlg (\onPress -> set ok [on command := onPress Nothing])
       return ()


So, in my case, I'd like to be able to remove 'h' & 'cpp' pages in DB
in order not to clutter the space on the desktop.

Maybe I'm wrong, but I'm not sure how DB's support for different build
systems can be of help do wxhaskell development.

Dave> Bottom line is maturity.  wxWidgets is considered a mature GUI
Dave> toolkit.  DialogBlocks is equally considered a mature IDE/RAD
Dave> tool for wxWidgets.

This is quite important aspect of the tool which I greatly appreciate.

Dave> DialogBlocks may not look as impressive as other 'eye candy'
Dave> interfaces, but it's not just a façade, it's true
Dave> design/development power!

Well, DB looks impressive to me by being very 'clean'.

Dave> You might like to have a look at a basic presentation of a
Dave> simple, fundamental tutorial for a wxWidgets application in
Dave> DialogBlocks.  Might I suggest?

Yep.

Dave> A Simple Editor: Sizers Tutorial - Navigable HTML Files in Zip
Dave> archive

I picked that one.

Dave> Not only will you get a basic hands-on experience with wxWidgets
Dave> sizers, but you'll also see, incidentally, how a DialogBlocks
Dave> wxWidgets application is instantiated.  Walk through it in DB,
Dave> takes less than half an hour.  It will give you a pretty good
Dave> handle on wxWidgets and DB.  A place to start working from and to
Dave> develop new questions from.

It took me some more time, but, I was also interrupted often by some
other tasks I had to do - very nice learning experience.

Dave> I would then suggest trying to do the same in wxFormBuilder.

That I'll try tomorrow...

Dave> It's a bit more problematic and 'logical' procedural steps in
Dave> building an application are not provided.  You have to know what
Dave> you want and what comes next ahead of time in the context of
Dave> wxWidgets, wxFormBuilder will offer no paths (it basically
Dave> implies that any wxWidgets element may exist anywhere in any
Dave> application, which is, of course, not true!).  I'm not saying it
Dave> cannot be done with wxFormBuilder, or Code::Blocks or others,
Dave> just that it's easier and requires less 'technical' input on the
Dave> user's part in DB.

...and I've to repeat with DB as well, but this time by just focusing
on XRC aspect 'cause all the C++ code generated by DB is of no value
to me. :-)


Sincerely,
Gour

--

Gour (Gmail)  | Hlapicina, Croatia  | GPG key: 9AA2B054
---------------------------------------------------------------------------

#6333 From: Gour <ggdasa@...>
Date: Mon Jan 25, 2010 10:04 pm
Subject: Re: DialogBlocks vs. others?
ggd_108
Send Email Send Email
 
On Mon, 25 Jan 2010 14:49:33 -0600
>>>>>> "Jester" == The Devils Jester <thedevilsjester@...> wrote:

Jester> I come from a Visual Basic/Windows background, and when I moved to
Jester> Linux and started developing with wxWidgets I was stuck in the
Jester> mind frame of static size and positioning like Visual Basic.

Fortunately, I never had to do anything with VB. ;)


Jester> found a couple wxWidgets GUI applications that allowed me to do
Jester> this, but I never really enjoyed them.  I stopped using wxWidgets
Jester> and moved to FOX for awhile, did some development in it, got used
Jester> to the sizer concept, and when I moved back to wxWidgets (native
Jester> themes ftw),

Jester> I tried a few of those GUI building applications that
Jester> I used before, and they just were not very intuitive.  Once I got
Jester> used to the sizer concept, DialogBlocks was the only GUI/RAD/IDE
Jester> that just made sense.

Hearing your experience, I wonder how wxDesigner compares to DB since
it is written by another wx dev who must know intricacies of wxWidgets
pretty well, but at the same time 'evaluation version' seems crippled?

Jester> Julian has always answered my questions quickly, and responded to
Jester> issues, bug reports and feature requests in a very timely
Jester> fashion.  I prefer DB over every application that I have tried,
Jester> and I recommend it to anyone that is looking to get into wxWidgets.

Thank you for sharing.

Yeah, I'm aware that at this point of time, being totally new with
wxwidgets I see mostly from external point of view and cannot properly
value what does it mean when you are in the midst of the work facing
the wall of some problem and when you count when the fix/help will
arrive...


Sincerely,
Gour

--

Gour (Gmail)  | Hlapicina, Croatia  | GPG key: 9AA2B054
---------------------------------------------------------------------------

#6334 From: "Dave Silvia" <dsilvia@...>
Date: Mon Jan 25, 2010 10:26 pm
Subject: Re: DialogBlocks vs. others?
ddotedotsdot
Send Email Send Email
 
Hi,

My last comment re: the subject.  If answers to your questions re: XRC
generated, how different things apply to wxWidgets, how one might approach
the matter in view of the fact that you'll be coding in a language that no
wxWidgets IDE/RAD tool addresses, and other such miscellany, I would opt for
DB simply because Julian is much more likely than any other source/resource
to try to give definitive answers *and* try to address changes that might be
made in DB to help (providing, of course, they have applicability to XRC in
general and DB specifically).  You will find him, by and large, to be an
easy person to get along with, someone who is genuinely interested in
broadening the scope not only of his IDE/RAD package, but wxWidgets in
general.  Plus, he has a bit more time for it (not a lot), it being his main
focus.  Dr. Roebling, on the other hand, has an unrelated vocation, he's an
M.D. and that does take a significant amount of his time.  Although, he,
too, has the same interests for wxWidgets and is a good source/resource.

jmtcw:

thx,
Dave S.




--------------------------------------------------
From: "Gour" <ggdasa@...>
Sent: Monday, January 25, 2010 4:04 PM
To: <anthemion-devtools@yahoogroups.com>
Subject: Re: [anthemion-devtools] DialogBlocks vs. others?

[extract from message attachment I received in my email.  no message body.]

Jester> Julian has always answered my questions quickly, and responded to
Jester> issues, bug reports and feature requests in a very timely
Jester> fashion.  I prefer DB over every application that I have tried,
Jester> and I recommend it to anyone that is looking to get into wxWidgets.

Thank you for sharing.

Yeah, I'm aware that at this point of time, being totally new with
wxwidgets I see mostly from external point of view and cannot properly
value what does it mean when you are in the midst of the work facing
the wall of some problem and when you count when the fix/help will
arrive...

#6335 From: Gour <ggdasa@...>
Date: Mon Jan 25, 2010 10:53 pm
Subject: Re: DialogBlocks vs. others?
ggd_108
Send Email Send Email
 
On Mon, 25 Jan 2010 16:26:58 -0600
>>>>>> "Dave" == "Dave Silvia" <dsilvia@...> wrote:

Hi Dave,

Dave> I would opt for DB simply because Julian is much more likely
Dave> than any other source/resource to try to give definitive answers
Dave> *and* try to address changes that might be made in DB to help
Dave> (providing, of course, they have applicability to XRC in general
Dave> and DB specifically).

This is very strong.

Dave> You will
Dave> find him, by and large, to be an easy person to get along with,
Dave> someone who is genuinely interested in broadening the scope not
Dave> only of his IDE/RAD package, but wxWidgets in general.

Heh, let him persuade to try Haskell and bingo! :-D

I'm also interested to help wxWidgets becoming stronger so that
open-source community can continue having viable alternative to
corporate toolkit.

Dave> Plus, he has a bit more time for it (not a lot), it being his
Dave> main focus.

Another very important aspect...Thank you.

Dave> Dr. Roebling, on the other hand, has an unrelated vocation, he's
Dave> an M.D. and that does take a significant amount of his time.

Ohh, that's impressive. My wife is M.D. so I can understand how much
time he has.


All in all, your replies are very helpful and to the point that DB is
the best supported tool with good prospect to continue being so.

Moreover, I hope that I'll be, after some time, being able to help
wxhaskell project to become better citizen in the wxWidgets world -
main dev wrote me that atm wxhaskell supports 2.8.10, and 3.0 will be
supported soon after official release.

Let's hope that wxhaskell development will become more appealing to
wider wxWidgets audience so that one day DB will generate Haskell code
as well.


Sincerely,
Gour

p.s. On Sunday we're going to vacation, and then we'll start with
learning wxhaskell (hopefully) using DB. ;)

--

Gour (Gmail)  | Hlapicina, Croatia  | GPG key: 9AA2B054
---------------------------------------------------------------------------

#6336 From: "Dave Silvia" <dsilvia@...>
Date: Mon Jan 25, 2010 11:46 pm
Subject: Re: DialogBlocks vs. others?
ddotedotsdot
Send Email Send Email
 
Happy to have been of help, presuming I was...

thx,
Dave S.

--------------------------------------------------
From: "Gour" <ggdasa@...>
Sent: Monday, January 25, 2010 4:53 PM
To: <anthemion-devtools@yahoogroups.com>
Subject: Re: [anthemion-devtools] DialogBlocks vs. others?

#6337 From: "ronys" <ronys@...>
Date: Tue Jan 26, 2010 6:58 pm
Subject: MFC stringtable import utility?
ronys_5
Send Email Send Email
 
Hi,

I'm porting an application from Windows MFC to wxWidgets. The Windows app has
quite a few strings defined as STRINGTABLE resources in .rc2 files. These are
loaded by the app at runtime, using a mechanism that supports
internationalization.
Is there a tool for importing the MFC stringtables into a form that can be used
by wxString, or am I on my own here?

Cheers,

   Rony

#6338 From: Gour <gour@...>
Date: Wed Jan 27, 2010 12:44 pm
Subject: support for other languages
ggd_108
Send Email Send Email
 
Hello,

in the light of my recent thread here, I must say that I like DB so
far.

Otoh, since I do not see myself going back into C++ programming (did
it long ago in the era of Zortech compiler, but C++ evolved quite a
bit since that time), I wonder if there is some plan to support code
generation for other languages in DB? I see that even Python is not
supported although many other designers do (wxglade, wxdesigner,
wxformbuilder...)?


Sincerely,
Gour

--

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

#6339 From: Julian Smart <julian@...>
Date: Wed Jan 27, 2010 4:39 pm
Subject: Re: support for other languages
felixcarswell
Send Email Send Email
 
Hi Gour,

Gour wrote:
> Hello,
>
> in the light of my recent thread here, I must say that I like DB so
> far.
>
> Otoh, since I do not see myself going back into C++ programming (did
> it long ago in the era of Zortech compiler, but C++ evolved quite a
> bit since that time), I wonder if there is some plan to support code
> generation for other languages in DB? I see that even Python is not
> supported although many other designers do (wxglade, wxdesigner,
> wxformbuilder...)?
>
Alas no, I have concentrated on support for C++ and I don't currently
have plans for other languages - sorry! There's so much code involved in
generating C++ it would be several months' work to generate for other
languages, and it's hard to find that amount of time...

Regards,

Julian

#6340 From: Gour <gour@...>
Date: Wed Jan 27, 2010 5:21 pm
Subject: Re: support for other languages
ggd_108
Send Email Send Email
 
On Wed, 27 Jan 2010 16:39:42 +0000
>>>>>> "Julian" == Julian Smart <julian@...> wrote:

Hello Julian,

Let me first congratulate you for bringing such a nice library
into life which we'll use with another fine product called Haskell
language. :-)

Julian> Alas no, I have concentrated on support for C++ and I don't
Julian> currently have plans for other languages - sorry! There's so
Julian> much code involved in generating C++ it would be several
Julian> months' work to generate for other languages, and it's hard to
Julian> find that amount of time...

OK. Fair-enough. I still believe that after returning from vacation
we'll buy oneself one copy of DB...

Otoh, on wxhaskell-users list we're developing about XRC. Main dev
listed few difficulties with them:

- It is not really possible to control an XRC-based menu very well. As
an example, I have never succeeded in disabling a menu option

- I also have not succeeded in getting XRC to work with wxHaskell
custom controls (and I've tried fairly hard). This is currently a
show-stopper for me. I very much doubt that this will ever work
without putting wxHaskell support into a GUI builder, since wxHaskell
custom widgets do not look (to C++) quite the same as C++ custom
widgets.

There are some more issues mentioned (here is the cross-post
http://article.gmane.org/gmane.comp.lang.haskell.cafe/69605)

Well, the remaining option is that support is added by wxhaskell devs,
but it would probably mean it won't be possible to find its place
within DB...


Sincerely,
Gour

--

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

#6341 From: Domingo Becker <domingobecker@...>
Date: Wed Jan 27, 2010 10:14 pm
Subject: icon in notification area
domingobecker
Send Email Send Email
 
I'm currently working on an application that prints tickets on a
fiscal ticket printer (Epson's Argentina model). It works fine now.
The problem I needed to solve is that my customer doesn't want to
spend money in more than one fiscal ticket printer, and there are
several points of sale that should print in that fiscal ticket
printer.

Now I want to hide the application and only show an icon in the
notification area.
Is there an example I may see on how to do this with wxWidgets?

wx 2.8.10, win XP, mingw

kind regards

Domingo Becker

#6342 From: Bob Paddock <bob.paddock@...>
Date: Thu Jan 28, 2010 2:29 am
Subject: Re: support for other languages
dialogblocks
Send Email Send Email
 
> Otoh, since I do not see myself going back into C++ programming (did
> it long ago in the era of Zortech compiler,

http://www.digitalmars.com is what it has become today.
It is supported by DB and WX.  Alas it too has become outdated,
as it will no longer build Boost.


--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/
http://www.designer-iii.com/
http://www.unusualresearch.com/

#6343 From: Gour <gour@...>
Date: Thu Jan 28, 2010 7:13 am
Subject: Re: support for other languages
ggd_108
Send Email Send Email
 
On Wed, 27 Jan 2010 21:29:46 -0500
>>>>>> "Bob" == Bob Paddock <bob.paddock@...> wrote:

Bob> http://www.digitalmars.com is what it has become today.

Yeah, I know...D language...Walter is Bright guy. ;)

But, now I'm focused on Haskell...


Sincerely,
Gour

--

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
----------------------------------------------------------------

Messages 6314 - 6343 of 7465   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help