You'll note, toward the bottom of the Configurations Property Sheet, there
is a property called CFG.  You might assign, for instance, the value
"Static" to this which then becomes the trailing designation for the build
and lib dirs (i.e., vc_libStatic) for your static build and "Dynamic" for
your shared object build (i.e., vc_libDynamic).

This has been around in wxWidgets for quite some time, but no one ever used
it.  When I had need of it, I researched it and asked Julian if it were
possible to add this to DB.  He did this quite some time ago.  However, even
after answering this question several times in anthemion-devtools and
wxMS_developers, and the fact that it appears in some of my tutorials and
demos and the video tutorial on building under several platforms with
wxWidgets and DialogBlocks, it still goes largely unused!%~{

You know what they say; "You can lead a horse to water, but you can't make
them do the backstroke!"

HTH:

Dave S.

Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/

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


----- Original Message -----
From: "Andreas Goebel" <a-goebel@...>
To: <anthemion-devtools@yahoogroups.com>
Sent: Sunday, October 18, 2009 4:30 AM
Subject: [anthemion-devtools] Use static runtime linking


> Hi,
>
> for one of my projects I´d like to use static runtime linking. For this,
> wxWidgets has to be rebuilt.
>
> However, for another project I must use dynamic runtime linking, and I´d
> like to keep that build of wx intact.
>
> How can I change the build-directory for wx within my dialogBlocks -
> Project?
>
> Regards,
>
> Andreas
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi
I am looking for an example of how to embed the Microsoft browser control into a
wxWidgets app.

Thanks.

Paschal

Hi!

I've changed the procedure for joining this group.  It has always been open,
with no restriction.
I changed this to membership on approval to try to curb the spammers who
periodically join and send
garbage messages to the group.  I've been avoiding doing this because, frankly,
I have plenty
to keep me busy as it is.  However, this last spammer who just joined the group
posted an advert for
pornography, and that was definitely a last straw.  Not that I, personally, have
issues with
pornography, as a matter of fact I feel everyone has the right to voice their
opinions.  I respect
their rights, and expect the group's rights to be respected, too.  Since
pornography is a bit of a
charged issue to some people, some of whom may be members of this group, and in
deference to their rights,
all new memberships will require approval.  This is in hopes that a lowered
volume of spam will result,
not just pornography, but all unsolicited ads to the group which have no direct
bearing on wxWidgets,
wxWidgets on Microsoft Windows, and wxWidgets IDE's.

I'm hoping this will meet the approval of the group, because, after all, it is
not really my group,
but yours.

Sincerely,
Dave S.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the wxMS_developers
group.

   File        : /GNU.zip
   Uploaded by : db_vs_dave <dsilvia@...>
   Description : GNU Compiler Collection and Make References

You can access this file at the URL:
http://groups.yahoo.com/group/wxMS_developers/files/GNU.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

db_vs_dave <dsilvia@...>

Hi!

If you mean a 'traditional' histogram (bar chart), a wxGrid can be used for
such a purpose. There's a _very_ basic demo of the process. Here's where you
can find it:

http://www.wxcodex.net

In the green menu to the left, click the 'Demo' radio button, then click the
'Go' button at the bottom of that same menu. It's on the second page of
demos, I think. It has all the code for building and a Makefile for Linux
GCC, makefile.gcc for MinGW, and GridHist.vcproj/GridHist.sln for Visual
Studio. It also contains a DialogBlocks project file (that's what was used
to 'create' the GUI and incidentals). You do not have to use DialogBlocks to
use the demo, all the resultant pieces are there.

HTH:

thx,
Dave S.

Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/

wxWidgets Code Exchange
http://wxcodex.net/

----- Original Message -----
From: "Guy Rutenberg" <guyrutenberg@...>
Newsgroups: comp.soft-sys.wxwindows
To: <wx-users@...>
Sent: Thursday, April 30, 2009 9:26 AM
Subject: Histogram Widget?


>
>
> Hi,
>
> I'm looking for a widget to display histograms of data (not images) as
> means of data visualization.
>
> Does anyone knows about such widget for wxWidgets?
>
> Regards,
>
> Guy
>
> ----
> http://www.openyahtzee.org/ - An open-source Yahtzee game written in
> wxWidgets
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users

Hi!

Thank you for the input!:-) Most interesting!;)

It's nice to see that I wasn't the only one who didn't automatically forgive
'his highness', Linus Torvalds, for his parochialism, disclaimed or not!:-)
You'll 'catch more flies with honey than with vinegar', providing, of
course, catching flies is one of your hobbies and their not 'pop-flies'!;)

If there's one attitude in the world of software I admire most it's
'TMTOWTDI'; the 'byword' acronym of Perl. And even though Perl aficionados
use the term somewhat 'parochially' themselves, i.e., more than one way in
Perl, it's nonetheless a universal truism.

A particular way to handle a problem may not be the 'best' way, in fact,
more often than not, it is not!:-o More realistically, it's the most
suitable way from the available resources in the extant environment, and,
btw, it has some 'personal' appeal, for completely unrelated reasons, to one
someone involved.

I would love to see a git type of paradigm available on all platforms,
complete with a universal (i.e., not different for each platform and
maintained by unrelated teams) GUI/UI, provision for plugins, and an API. To
me, that would be the ultimate. But that whole world is somewhere in the
future still, and not here today. So, I must make due with the resources at
hand for my environment (and that I personally like!;).

This is definitely a good piece of history in software engineering to follow
as it unfolds!;)

thx,
Dave S.

----- Original Message -----
From: "Soeren.Meyer-Eppler" <Soeren.Meyer-Eppler@...>
To: <anthemion-devtools@yahoogroups.com>
Sent: Sunday, April 05, 2009 12:46 PM
Subject: Re: [anthemion-devtools] On the subject of source control...


> Eric Sink, one of the Vault Version Control system managers/developers,
> blogs about decentralised version control and raises some good points.
> He's biased of course, but his summary is nevertheless worth a read:
>
> http://www.ericsink.com/entries/dvcs_dag_1.html
>
> http://www.ericsink.com/entries/dvcs_dag_2.html
>
> http://www.ericsink.com/entries/merge_history.html
>
> http://www.ericsink.com/entries/why_is_git_fast.html
>
> cheers,
>
>    Sören
>
> --
> Sören Meyer-Eppler
> software developer
> Soeren.Meyer-Eppler@...
> http://www.BuschnicK.net
>
>
> ------------------------------------

I thought I might share my experience of the last week, spent looking for a
good, flexible, easy to use, simple to
learn, and *cheap* (read: 'free or less'!;) project management/source control
package. In the years I've been around
software, there have been 3 fairly high rated and widely used free, open source,
source control packages: RCS, CVS,
and SVN. All three quite good 'low level', command line based applications.
Unfortunately, with the possible exception
of CVS and Tortoise, easy to use GUI front ends are few and far between. I hit
about a half dozen 'wrappers' for SVN,
and in my most humble opinion (and it's very true!;), not a one is worth too
much. TortoiseSVN is the most likely
front runner, but even it is not as good as it's predecessor, TortoiseCVS.
Additionally, it suffers from the same
drawback of TortoiseCVS: no true GUI interface, simply a set of system context
menus. A couple of others showed some
promise, but they haven't been actively worked on of late and sadly lack a good
deal of basic functionality.
Speaking of which, that seems to be the biggest 'lack' of all front ends for
SVN, basic functionality for administering
the database (repository, depot, stream, what-have-you). I would think this
would have been one of the first things
out of the chute, but apparently my thinking is wrong!;) For some unknown
reason, none of the front end applications
want to tackle management, just day to day checkin/checkout. But here's hoping
all of that will change in the near
future with CollabNet coming out with a true front end application, at least for
Windows, CollabNet Desktop (and, no,
I'm not talking about the product that previously held that name. That is/was
more or less a plugin for Visual Studio).
I tried using CollabNet Desktop (a.k.a., 'Microsoft Windows Edition'), but it's
only a beta, and still quite in its
infancy.

Biting the bullet, I decided to look at the possibility of shareware/commercial
project management/source control
resources. Here I was a little more successful, although not to a great degree
(say, maybe 4-15% greater success?).
I have been a long time user of Araxis Merge, to my thinking, one of the better
'diff' programs around today. It is
commercial, but not bankrupting. In delving a bit deeper into Merge, I
discovered a fact I was hitherto unaware of;
it's designed to seamlessly work with other 3rd party source control packages,
notably SVN and Perforce. I took a
look at the SVN portions of Merge, but for whatever reason I couldn't easily get
them to work. So, I started looking
at Perforce. In that same time frame, I found both Perforce and PureCM in
wikipedia and thought it might be a good
idea to look at PureCM while I was at it.

Both Perforce and PureCM are UK based companies. I believe Perforce has been
around the longest (not sure though).
Perforce has both 32 and 64 bit versions, PureCM only 32 bit. Perforce's UI has
more functionality, and of all the
GUI's I looked at, it was the only one that actually had clear, concise
documentation on administration of your
database (which they call a 'depot'), and the functionality was actually in the
GUI itself!8-o It wasn't a set of
(usually erratic and not always correct) instructions on how to access the p4
(counterpart of svn/svnadmin)
administration commands from the command line!8-O [I often wonder about it when
people take the time to check out and
document what commands to give at the commandline. Wouldn't it take only
marginally longer to forego that and just
write the UI for same?!%=o] Both Perforce and PureCM have a non-terminating
(i.e., free forever) evaluation which
allows a maximum of 2 users, one for admin and one for user. Perforce puts it
right up front in many places whilst
PureCM keeps it tucked away in little corners. If you're not looking for it (and
I was since the wikipedia article
stated it was a free two-seater!;), you're very likely to miss it. I suppose
there are pros and cons to both
strategies, and most likely based on their price per seat. One needs to have you
know it's there so you'll take a look
at their product and not be scared off by the $$$'s, the other's price per seat
is lower and they probably depend more
on cash flow, so they chance your not being put off by their pricing.


Perforce Licensing

The Perforce End User License Agreement (PDF) is our standard commercial
licensing agreement. All Perforce software
you download is fully functional for two users and five client workspaces when
used without a license. A Perforce
license enables the Perforce Server to support more users and an unlimited
number of workspaces and also entitles you
to Perforce Technical Support.

up to 20 users, $14,800


PureCM

Also free for 2 users.

minimum paid commercial license, $1500 for 5 users
There is a 'starter pack' for $1000, but from what I read in the FAQ, it's
really not as good a deal as it sounds,
especially if you may/will expand.


Perforce seems to be the more robust of the 2 (and the pricier if 2 seats won't
do for you!;) Both claim defect
tracking capability ('bugs'), but it seems peripheral at best.

They are both proprietary, but also 'one stop shop', you won't have to chase
about the network getting support
software (as is the case with almost all free open source products).
Additionally, being commercial, they have a
certain vested interest in stability, customer satisfaction, and performance. As
such, their support is more
responsive, their documentation is far and away of higher caliber than open
source docs tend to be. All the bases are
covered, and without having to wade through web links to get there from here.
Everything that is there is pretty much
on the money and accurate, no guess work. Also, the UI for both is much more
professional, a bit more intuitive
(although they, too, suffer from the same lack of GUI design finesse as open
source products, just not to such a
high degree!;)

This is my first venture into the world of source control in many years (aside
from some casual cvs brushes in the
recent past for obtaining online source). In the 80's and 90's I was quite
fluent in RCS/SCCS, my occupation demanded
it (aerospace and telecommunication GUI development, mostly on Sun Microsystems
boxes). The state of the art has made
some strides, inner workings wise. It's just a shame that no one (especially in
the open source community) seems to
want the 'thankless' jobs of testing, integration, and documentation. For the
most part, I was seriously disappointed
in most all offerings, free and commercial. But no one knows what tomorrow may
bring!;)

For right now, I'm leaning toward free Perforce, coupled into the Araxis Merge I
already own, and possibly using
Araxis' Ketura as the tracking portion. They all seem to fit together nicely and
the total cost is nominal. Araxis has
a package deal for Merge and Ketura, and since it is a fairly tight couple with
Perforce, I think it might just fill
the bill for me. If you are a single developer, like myself, with only a handful
of projects going at a time, you may
find Perforce or PureCM a viable alternative to SVN. Especially since all 3 are
free under these circumstances!;)

fyi & jmtcw:

thx,
Dave S.

Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/

wxWidgets Code Exchange
http://wxcodex.net/

...btw, if you have separate static and shared wxWidgets libraries, this
model works quite well for segregating these, too!;)

:-Dave S.
----- Original Message -----
From: "Dave Silvia" <dsilvia@...>
To: <wx-users@...>
Cc: "anthemion-devtools" <anthemion-devtools@yahoogroups.com>;
"wxMS_developers" <wxMS_developers@yahoogroups.com>
Sent: Wednesday, March 25, 2009 10:17 PM
Subject: Re: Separate output directories for different Visual Studio
versions


> I've been dealing with this scenario for a couple of years now. It's quite
> simple to deal with. I am a DialogBlocks user and have been almost since
> my first encounter with wxWidgets. At one time I approached Julian Smart
> with my need to have various versions of wxWidgets for my separate builds
> of not only Microsoft platforms, but also my various flavors of GCC. Some
> way to have a central build setup that could share one set of sources
> branched out into many versions for wxWidgets libraries. He saw the need,
> but didn't have any immediate solutions via DialogBlocks or wxWidgets
> proper.
>
> After looking over the build process of wxWidgets, I noticed a variable
> there that was virtually everywhere, but never really used: CFG. This
> variable is appended to the library _and_ build directories universally. I
> brought this to Julian's attention, and after some minor preliminary
> discussion, he included the variable in the property sheet for compiler
> configurations in DialogBlocks. He also installed several DialogBlocks
> variables for the separate MSVCDIR variables (as DialogBlocks designates
> them), however, these are not yet fully implemented in DialogBlocks for
> 'automagic' switching for the individual compiler configurations, but I'm
> sure this will be done at some future date.
>
> Now, this does not mean that I'm advocating you use DialogBlocks (although
> I do believe it is a wise decision for any serious developer to make!;),
> it merely means that, 'yes', there is a way to keep your separate builds.
> When building wxWidgets (using the distributed makefile(s) as DialogBlocks
> does), simply add a command line definition for CFG, e.g.,
> '/DCFG=.VC90.Win32', the resultant directory names in build and lib will
> be 'vc_msw[d].VC90.Win32' and 'vc_lib.VC90.Win32', respectively. All you
> must needs then do is point your individual builds at the appropriate lib
> directory!;)
>
> BTW, another find advantage to DialogBlocks is that it properly builds
> wxWidgets for any platform that the wxWidgets toolkits runs on. It 'knows'
> all the correct parameters to pass to the distribution makefiles to effect
> a correct build for whatever flavor of compiler you might have!:-) Even
> though DialogBlocks is a commercial IDE, its 'forever' evaluation version
> (free!!!) will reliably build wxWidgets for any platform, quite worth its
> price (free!!!?).
>
> HTH:
>
> thx,
> Dave S.
>
> Development with wxWidgets on MSWindows
> http://tech.groups.yahoo.com/group/wxMS_developers/
>
> wxWidgets Code Exchange
> http://wxcodex.net/
>
> ----- Original Message -----
> From: "Kenneth Porter" <shiva.blacklist@...>
> Newsgroups: comp.soft-sys.wxwindows
> To: <wx-users@...>
> Sent: Wednesday, March 25, 2009 8:28 PM
> Subject: Separate output directories for different Visual Studio versions
>
>
>>
>>
>> I need to maintain an app with both VS2005 and VS2008 builds, and will
>> probably soon need to get a VS2010 build going. (Fortunately, I've been
>> able to retire my VC6 build.) Currently I clean my wxWidgets tree and
>> rebuild to switch versions, but it would be nice to be able to leave all
>> versions built in separate output directories. Are there any plans to
>> have
>> that in the standard distro?
>>
>> I'm linking to wx statically (so my demo application and my non-GUI
>> library
>> each have their own copies of wx that don't know about each other), and
>> to
>> the compiler runtime dynamically (application and all 3rd party libraries
>> share one copy of the compiler runtime).
>> _______________________________________________
>> wx-users mailing list
>> wx-users@...
>> http://lists.wxwidgets.org/mailman/listinfo/wx-users
>
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users

I've been dealing with this scenario for a couple of years now. It's quite
simple to deal with. I am a DialogBlocks user and have been almost since my
first encounter with wxWidgets. At one time I approached Julian Smart with
my need to have various versions of wxWidgets for my separate builds of not
only Microsoft platforms, but also my various flavors of GCC. Some way to
have a central build setup that could share one set of sources branched out
into many versions for wxWidgets libraries. He saw the need, but didn't have
any immediate solutions via DialogBlocks or wxWidgets proper.

After looking over the build process of wxWidgets, I noticed a variable
there that was virtually everywhere, but never really used: CFG. This
variable is appended to the library _and_ build directories universally. I
brought this to Julian's attention, and after some minor preliminary
discussion, he included the variable in the property sheet for compiler
configurations in DialogBlocks. He also installed several DialogBlocks
variables for the separate MSVCDIR variables (as DialogBlocks designates
them), however, these are not yet fully implemented in DialogBlocks for
'automagic' switching for the individual compiler configurations, but I'm
sure this will be done at some future date.

Now, this does not mean that I'm advocating you use DialogBlocks (although I
do believe it is a wise decision for any serious developer to make!;), it
merely means that, 'yes', there is a way to keep your separate builds. When
building wxWidgets (using the distributed makefile(s) as DialogBlocks does),
simply add a command line definition for CFG, e.g., '/DCFG=.VC90.Win32', the
resultant directory names in build and lib will be 'vc_msw[d].VC90.Win32'
and 'vc_lib.VC90.Win32', respectively. All you must needs then do is point
your individual builds at the appropriate lib directory!;)

BTW, another find advantage to DialogBlocks is that it properly builds
wxWidgets for any platform that the wxWidgets toolkits runs on. It 'knows'
all the correct parameters to pass to the distribution makefiles to effect a
correct build for whatever flavor of compiler you might have!:-) Even though
DialogBlocks is a commercial IDE, its 'forever' evaluation version (free!!!)
will reliably build wxWidgets for any platform, quite worth its price
(free!!!?).

HTH:

thx,
Dave S.

Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/

wxWidgets Code Exchange
http://wxcodex.net/

----- Original Message -----
From: "Kenneth Porter" <shiva.blacklist@...>
Newsgroups: comp.soft-sys.wxwindows
To: <wx-users@...>
Sent: Wednesday, March 25, 2009 8:28 PM
Subject: Separate output directories for different Visual Studio versions


>
>
> I need to maintain an app with both VS2005 and VS2008 builds, and will
> probably soon need to get a VS2010 build going. (Fortunately, I've been
> able to retire my VC6 build.) Currently I clean my wxWidgets tree and
> rebuild to switch versions, but it would be nice to be able to leave all
> versions built in separate output directories. Are there any plans to have
> that in the standard distro?
>
> I'm linking to wx statically (so my demo application and my non-GUI
> library
> each have their own copies of wx that don't know about each other), and to
> the compiler runtime dynamically (application and all 3rd party libraries
> share one copy of the compiler runtime).
> _______________________________________________
> wx-users mailing list
> wx-users@...
> http://lists.wxwidgets.org/mailman/listinfo/wx-users

Hi!

This is an application which was originally intended to be a tutorial.
When it grew so large that 'tutorial' was an inappropriate term and
the task of authoring such a tutorial grew to a scope beyond simple
descriptions, it graduated to a demo. However, it soon outgrew even
that classification. It is, for all practical intents and purposes, a
complete application for manipulation of images in an MDI paradigm
written solely in wxWidgets. One says 'complete', but then, no piece
of software ever attains that ultimate goal. It is complete in the
sense that it addresses its current design parameters to a level of
usefulness sufficient for practical application.

Its name implies that it is a tool for browsing graphic images, much
like the common Windows tool which has had various names through
several incarnations, being more or less a viewer and little more.
However, the name is misleading. It has many more functions than
simple viewing, as a perusal of the built in help will reveal. One
can adjust size, rotation, various coloring parameters and schemes,
mirror, convert to other formats, and more. On the other hand, it is
by no means a tool of the complexity or caliber of PhotoShop, Paint
Shop Pro, The Gimp, and other master graphics tools. Such
functionality is beyond the intrinsic scope of wxWidgets alone, and
certainly beyond expertise of MDIBitmapBrowser's author to write from
'scratch'. But it is a most useful tool, in and of itself. Besides it
is a practical 'guide book' for manipulating images in wxWidgets and
illustrates the capabilities of MDI for more than just simple
multiple document display. In view of all this, MDIBitmapBrowser
should be of some interest to a variety of developers and users in
the wxWidgets and associated communities.

The full source, along with the DialogBlocks project used to launch
the graphics and the various platform 'build' files (.sln/.vcproj and
makefiles), sample images to use for 'safe' testing of your build,
and a 'Gotchas' directory listing the ins and outs discovered in
development, are available in a zip archive at:

wxWidgets Code Exchange

In the 'Applications' section.

NOTE: MDI is a 'unique' Microsoft-ism. True MDI implementation only
exists on Windows platforms. However, the wxWidgets toolkit 'adapts'
the MDI paradigm to wxNotebook. The look and feel, obviously, are not
the same, but the basic functionality and methods for image
manipulation are the same. The ability to drag and drop from one MDI
frame to another, for example, is not available in non-Windows
Notebook mode, but drag and drop to other applications is still
possible. Some features were 'modified' for non-Microsoft platforms
and some simply left out.

Enjoy!Smile

thx,
Dave S.

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

The wxWidgets Code Exchange
http://www.wxCodex.net

Thanks for your reply, Ralph.

I added a zip file in the Files section called MVCTest.zip.
It contains a demo app to illustrate the MVC concept with wxWidgets.
The form contains a text box with a value, and 2 buttons: increment, decrement.

The project does not contain the events, though, because I am not sure how to do
it.

Who can help and make the app work? I guess there is more than one way to do it.
It could be interesting to discuss these.
You can post your solution to the Files section.
Thanks!

Kind regards,
Al


--- In wxMS_developers@yahoogroups.com, Ralph Pass <rppass@...> wrote:
>
> I derive my controller from Frame and put the events there.  My view
> creates a view given a wxDC.  My events pass relevant information to the
> model.  The events also decide if it was such that the views need to be
> updated.  It also checks the model to see if the model thinks the views
> need to be updated.
> Conceptually, I have the controllers separate from the models separate
> from the views.
>
> Ralph
>
> al_lo_ja wrote:
> >
> > Hello,
> >
> > I want a clear separation between the UI and the business logic.
> >
> > How do you achieve this? How do you organize your source files for
> > your applications? Which folders do you generally create?
> >
> > I have tried this for my first wxWidget application:
> > \main.cpp
> > \MyApp.h
> > \MyApp.cpp
> > \Controllers\MyAppController.h
> > \Controllers\MyAppController.cpp
> > \Models\MyAppModel.h
> > \Models\MyAppModel.cpp
> > \Views\MyMainWindow.h
> > \Views\MyMainWindow.cpp
> >
> > - main.cpp contains only DECLARE_APP(MyApp) and IMPLEMENT_APP(MyApp)
> > - the MyApp class inherits from wxApp. MyApp.cpp contains the OnInit
> > method and creates a MyAppController object
> > - the MyAppController object creates a MyAppModel object and a
> > MyMainWindow object
> > - MyAppModel is the core of the application and knows nothing about
> > the GUI
> > - MyMainWindow inherits from wxFrame and is the main window of the
> > application
> >
> > As you can see I've been trying to implement the MVC
> > (model/view/controller) pattern. But I don't know where's the best
> > place to put the event handlers.
> >
> > How do you organize your source files? Where do you catch events?
> >
> > Kind regards,
> > Al
> >
> >
>

I derive my controller from Frame and put the events there.  My view
creates a view given a wxDC.  My events pass relevant information to the
model.  The events also decide if it was such that the views need to be
updated.  It also checks the model to see if the model thinks the views
need to be updated.
Conceptually, I have the controllers separate from the models separate
from the views.

Ralph

al_lo_ja wrote:
>
> Hello,
>
> I want a clear separation between the UI and the business logic.
>
> How do you achieve this? How do you organize your source files for
> your applications? Which folders do you generally create?
>
> I have tried this for my first wxWidget application:
> \main.cpp
> \MyApp.h
> \MyApp.cpp
> \Controllers\MyAppController.h
> \Controllers\MyAppController.cpp
> \Models\MyAppModel.h
> \Models\MyAppModel.cpp
> \Views\MyMainWindow.h
> \Views\MyMainWindow.cpp
>
> - main.cpp contains only DECLARE_APP(MyApp) and IMPLEMENT_APP(MyApp)
> - the MyApp class inherits from wxApp. MyApp.cpp contains the OnInit
> method and creates a MyAppController object
> - the MyAppController object creates a MyAppModel object and a
> MyMainWindow object
> - MyAppModel is the core of the application and knows nothing about
> the GUI
> - MyMainWindow inherits from wxFrame and is the main window of the
> application
>
> As you can see I've been trying to implement the MVC
> (model/view/controller) pattern. But I don't know where's the best
> place to put the event handlers.
>
> How do you organize your source files? Where do you catch events?
>
> Kind regards,
> Al
>
>

Hello,

I want a clear separation between the UI and the business logic.

How do you achieve this? How do you organize your source files for your
applications? Which folders do you generally create?

I have tried this for my first wxWidget application:
\main.cpp
\MyApp.h
\MyApp.cpp
\Controllers\MyAppController.h
\Controllers\MyAppController.cpp
\Models\MyAppModel.h
\Models\MyAppModel.cpp
\Views\MyMainWindow.h
\Views\MyMainWindow.cpp

- main.cpp contains only DECLARE_APP(MyApp) and IMPLEMENT_APP(MyApp)
- the MyApp class inherits from wxApp. MyApp.cpp contains the OnInit method and
creates a MyAppController object
- the MyAppController object creates a MyAppModel object and a MyMainWindow
object
- MyAppModel is the core of the application and knows nothing about the GUI
- MyMainWindow inherits from wxFrame and is the main window of the application

As you can see I've been trying to implement the MVC (model/view/controller)
pattern. But I don't know where's the best place to put the event handlers.


How do you organize your source files? Where do you catch events?

Kind regards,
Al

Hi,

I've just uploaded a zip archive of modified CHM files for DialogBlocks
and wxWidgets. Modifications are:

1) Added more navigation

2) Added more search parameters

3) Added Favorites tab

I find "Favorites" handy for marking topics that apply to my current
project and/or topics I visit frequently. Search parameters provide for
narrowing down searches more effectively. Navigation provides for
back/forward and previous/next in a different way than what is included
in the pages in the CHM.

Enjoy,
Dave S.

----- Original Message -----

From: Andy Kellett

To: wxMS_developers@yahoogroups.com

Sent: Sunday, December 21, 2008 11:38 AM

Subject: RE: {Disarmed} Re: [wxMS_developers] Issues with POP3/wxSocketClient

Hi,

 

I posted some code in a separate message a few minutes ago, I just wanted to point out that the code runs error free when compiled in Release mode, and works as it should when saving the memory block to a file (and viewing it in a text editor). So the problems only appear in Debug mode on VC8/Vista 64. I can live with that I guess hehe.

 

--

Kind Regards,

 

Andy 'Fish-Guy' Kellett <andy@...>

http://www.f1-software.com

 

From: wxMS_developers@yahoogroups.com [mailto:wxMS_developers@yahoogroups.com] On Behalf Of Dave Silvia
Sent: Saturday, December 20, 2008 10:45 PM
To: wxMS_developers@yahoogroups.com
Subject: {Disarmed} Re: [wxMS_developers] Issues with POP3/wxSocketClient

 

Hi, Andy!

 

It's a little difficult to discuss the problem when the only information available is that you're using wxSocketClient. The problem may be further up the line. With only this one piece of information, one must assume that everything before the call to wxSocketClient methods/functions to retrieve the messages is performing correctly and that everything that was needed to be done before the wxSocketClient transactions was done!;)

 

It's much, much easier to talk about problems and issues if you attach your project (or a facsimile) to a posting you make from your email client (Yahoo! Groups does not do attachments!:-< ).

 

If you're using DialogBlocks, it's even easier to "share" as all one must needs do is attach the .pjd file (DialogBlocks project file). This will allow the receiver to build and run on their own system quite easily.

 

Any attachments should be in archive format (zip or other) to reduce size (.pjd's are quite large, but very compressible!;) and to make it more likely that the receiver's email client/antispam won't prevent its delivery.

 

The only thing I can do, from the information available here, is make a "swag" at a possibility. It appears that an "undocumented procedure" in wxSocketBase has to be performed first. I put it in quotes because it actually is documented, but only "before" the fact. That is, most wxWidgets "Base" classes are not intended to be used, only derived from. Hence, a developer (like me!;) doesn't often look at base classes in wxWidgets classes. The assumption being that the derived wxWidgets class is/has taken care of any parent class necessities.

 

In looking at the wxSocketBase documentation I see a blurb:

 

>>>>> 

wxSocketBase is the base class for all socket-related objects, and it defines all basic IO functionality.

Note: (Workaround for implementation limitation for wxWidgets up to 2.5.x) If you want to use sockets or derived classes such as wxFTP in a secondary thread, call wxSocketBase::Initialize() (undocumented) from the main thread before creating any sockets - in wxApp::OnInit for example.

 

<<<<< 

 

Now, it does say this is for wxWidgets up to 2.5.x, but it's the only "swag" I've got right now!:-( If it doesn't help, you might like to consider archiving an example and attaching it to an email client generated post.

 

HTH:

 
thx,
Dave S.
 
From a Braille bumper sticker...
 
If you can read this, you are too close!
 
 
wxMS_developers - Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/
 
wxWidgets Code Exchange
http://www.wxCodex.net/

> -- On Sat, 20 Dec 2008 21:20:29 -0500 Andy Kellett wrote --

> Hi,

> 

> I'm trying to write a really simple POP3 client using wxSocketClient which should connect to

> a POP3 account, and download all messages. It is to be part of my order handling processing

> system and I am having some odd issues that I can't seem to solve.

> 

> I am able to handle everything up to retrieving the actual message. I have tried a number of

> different methods to try and get this to work and so far I have not found anything that works

> consistently.

> 

> The first method was one I saw on a wxWidgets forum, involving a large string buffer. Call

> the Read() command and add the returned string to the main buffer string, parse the newline

> and remove the entire line to shorten the string, then repeat till the end of the message

> (single line with '.'). This only works a little bit and the socket seems to stop reading

> after a couple of messages, mid message, for no apparent reason.

> 

> Another idea I had was to allocate a block of memory big enough to hold the message, and call

> a Read() command with this buffer sixe, thinking the message would just read into memory

> where I can process it further. The problem here is that every so often, it doesn't work. It

> works on about 90% of the messages, but doesn't read in the entire thing, the LIST command

> for the next message still recovers parts of the previous message. The documentation for

> Read() doesn't state if there is a limit on the amount of data it transfers at one time, or

> if there is a way to wait for the buffer to contain a certain amount of data before reading.

> 

> I guess my question, is does someone have any POP3 retreival code anywhere, or could explain

> a process on how to make this work? I have found samples on the net for everything except

> POP3 hehe =)  Any help is greatly appreciated =) Thanks in advance.

> 

> --

> Kind Regards,

> 

> Andy 'Fish-Guy' Kellett <andy@...>

> http://www.f1-software.com

 

---

avast! Antivirus: Inbound message clean.

Virus Database (VPS): 081221-0, 12/21/2008
Tested on: 12/21/2008 6:04:07 PM
avast! - copyright (c) 1988-2008 ALWIL Software.

avast! Antivirus: Outbound message clean.

Virus Database (VPS): 081225-0, 12/25/2008
Tested on: 12/25/2008 4:38:10 PM
avast! - copyright (c) 1988-2008 ALWIL Software.

On Sat, Dec 20, 2008 at 9:20 PM, Andy Kellett <andy@...> wrote:
> Hi,
>
> I'm trying to write a really simple POP3 client using wxSocketClient which
> should connect to a POP3 account, and download all messages. It is to be
> part of my order handling processing system and I am having some odd issues
> that I can't seem to solve.

Take a look at http://mailfilter.sf.net 's code.  A lot of problems
are actually on the server end, especially if you are trying to deal with
unknown servers.  You can see some of the server work around in the
code comments.

> So the problems only appear in Debug mode on VC8/Vista 64. I
> can live with that I guess hehe.

64-bit problems more often than not, are a case where size_t should
have been used rather than int or unsigned int/long etc.