Finished with that so far and, just as importantly, I've established a
pattern to be followed, in the future.
To make it easy on myself, I've decided that settings will validate and
change when an individuel value is changed, or defcused, making it easy
changing colour (to, say, yellow or red on incorrect settings, say: obvious
incorrect e-mail etc...
The save button will thus merely commit changes to disk.
I'm also working on making the Mail Detail window auto-open when creating
or opening a new or saved document (email). (They're really "drafts" but
their extension is .eml.)
At least the first time. This should really be an option and thus be part
of the settings too.
There's only 1 Mail Detail view, but each document has a GUID as ID.
This way multiple documents can be open yet still share the same 1 and only
Mail Detail CDockablePane.
Finished with that so far and, just as importantly, I've established a
pattern to be followed, in the future.
To make it easy on myself, I've decided that settings will validate and
change when an individuel value is changed, or defcused, making it easy
changing colour (to, say, yellow or red on incorrect settings, say: obvious
incorrect e-mail etc...
The save button will thus merely commit changes to disk.
I've extended the menu to give you an idea of how it will look. I would
like the splash-screen to fade in and out. Jut for kicks. This may leave me
with precious Little Time for your recognisable toolbar, but you can't have
it all.
And bear in mind that it is a prototype, GUI only kind-of-thing. It is an orderly thing though.
Should I mention a short-coming or two it is that it is my belief that
DoDataExchange is getting obsolete and that OLE isn't Property thought in
or out.
I'm also working on making the Mail Detail window auto-open when creating
or opening a new or saved document (email). (They're really "drafts" but
their extension is .eml.)
At least the first time. This should really be an option and thus be part
of the settings too.
There's only 1 Mail Detail view, but each document has a GUID as ID.
This way multiple documents can be open yet still share the same 1 and
only Mail Detail CDockablePane.
Finished with that so far and, just as importantly, I've established a
pattern to be followed, in the future.
To make it easy on myself, I've decided that settings will validate and
change when an individuel value is changed, or defcused, making it easy
changing colour (to, say, yellow or red on incorrect settings, say: obvious
incorrect e-mail etc...
The save button will thus merely commit changes to disk.
I agree that DDE is getting seriously obsolete and it is one thing I would definitely replace. Mostly if something can be still made to work I would opt to keep it at least for the first version but DDE is an exception.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm hearing you'd loathe to see DDE in there anywhere.
Missing a proper RDBMS though, I'm afraid we will have to endure DDE for
the time being. It's a select few places though and, in no way pervasive.
Due to the time with which to IKEA this together we'll just have to live
with this for starters.
I know it's an insanely geeky thing to say, but I miss the power of a
virtual CListCtrl hooked up to a database to do proper bulkrow fetching.
Also, I know there's no Iove lost between you and Boost, but I am, at
least, pulling in the library that does REGEXes. It's mostly for demo
purporses "validating" an email.
I happen to know, from previous experience, that there is (was?) no
standardised way of doing this, but hopefully we can agree that there are a
couple of formats that are downright wrong.
Regards.
It is a fre select Places though sand, as Duch, Can be
I agree that DDE is getting seriously obsolete and it is one thing I would
definitely replace. Mostly if something can be still made to work I would
opt to keep it at least for the first version but DDE is an exception.
Could someone kindly explain to me, ideally in words of three syllables or
fewer, precisely to what end we need a relational database system? Please
don't misconstrue this as me being belligerent, or "not a team player"; if
you think we need it, we need it.
The only niche for it that I could possibly see is to run the personal
information manager/"address book"/contact list. If I'm correct (for
once), I think it'd be a reduplication of effort that'd be mighty hard to
justify. Keep in mind that there are billions and billions of
subtly-different, mutually-incompatible, yet tightly-integrated personal
information managers out there. Wouldn't it be better to focus our efforts
PIM-wise on something like, say, interoperability?
Think about it for a moment; I think it'd be just dandy if we could share a
PIM with Windows as a whole. Not to mention the space and effort we'd save.
Again, if I'm wildly off base, just ignore my ramblings.
I'm hearing you'd loathe to see DDE in there anywhere.
Missing a proper RDBMS though, I'm afraid we will have to endure DDE for
the time being. It's a select few places though and, in no way pervasive.
Due to the time with which to IKEA this together we'll just have to live
with this for starters.
I know it's an insanely geeky thing to say, but I miss the power of a
virtual CListCtrl hooked up to a database to do proper bulkrow fetching.
Also, I know there's no Iove lost between you and Boost, but I am, at
least, pulling in the library that does REGEXes. It's mostly for demo
purporses "validating" an email.
I happen to know, from previous experience, that there is (was?) no
standardised way of doing this, but hopefully we can agree that there are a
couple of formats that are downright wrong.
Regards.
It is a fre select Places though sand, as Duch, Can be
On Tuesday, January 1, 2019, Pete Maclean
petemaclean@users.sourceforge.net
wrote:
I agree that DDE is getting seriously obsolete and it is one thing I would
definitely replace. Mostly if something can be still made to work I would
opt to keep it at least for the first version but DDE is an exception.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
Well, as Pete and briefly touched on, it would avoid having to deal with
the (already/soon-to-be) obsolete DDE (Dynamic Data Exchange) and DDV
(Dynamic Data Validation) curently in use by MFC.
But yes, it's use, from a practical viewpoint, is limited. Limited but
robust. As it is, I save and load settings in a binary file. As the project
amasses Information, more such files will emerge. They cannot be
"nornalized" (look up the term as it applies to databases), being loose
files. So apart from being the inevitable future, more robust, and
normalizable it's "Just The Way These Things Are Done."
About normalization, imagine you have 10 contacts, all named "Smith". In a
database you'd be able to create a SURNAME table where "Smith" only occurs
once but have a unique ID. Other Places where you would write Smith you use
the ID instead, thus sacrifizing a little lookup time for space. A rather
contrived example, I admit, but there....
Could someone kindly explain to me, ideally in words of three syllables or
fewer, precisely to what end we need a relational database system? Please
don't misconstrue this as me being belligerent, or "not a team player"; if
you think we need it, we need it.
The only niche for it that I could possibly see is to run the personal
information manager/"address book"/contact list. If I'm correct (for
once), I think it'd be a reduplication of effort that'd be mighty hard to
justify. Keep in mind that there are billions and billions of
subtly-different, mutually-incompatible, yet tightly-integrated personal
information managers out there. Wouldn't it be better to focus our efforts
PIM-wise on something like, say, interoperability?
Think about it for a moment; I think it'd be just dandy if we could share a
PIM with Windows as a whole. Not to mention the space and effort we'd save.
Again, if I'm wildly off base, just ignore my ramblings.
On Tue, 1 Jan 2019 at 11:28, Soren Bro sbrothy@users.sourceforge.net
wrote:
I'm hearing you'd loathe to see DDE in there anywhere.
Missing a proper RDBMS though, I'm afraid we will have to endure DDE for
the time being. It's a select few places though and, in no way pervasive.
Due to the time with which to IKEA this together we'll just have to live
with this for starters.
I know it's an insanely geeky thing to say, but I miss the power of a
virtual CListCtrl hooked up to a database to do proper bulkrow fetching.
Also, I know there's no Iove lost between you and Boost, but I am, at
least, pulling in the library that does REGEXes. It's mostly for demo
purporses "validating" an email.
I happen to know, from previous experience, that there is (was?) no
standardised way of doing this, but hopefully we can agree that there are a
couple of formats that are downright wrong.
Regards.
It is a fre select Places though sand, as Duch, Can be
On Tuesday, January 1, 2019, Pete Maclean
petemaclean@users.sourceforge.net
wrote:
I agree that DDE is getting seriously obsolete and it is one thing I would
definitely replace. Mostly if something can be still made to work I would
opt to keep it at least for the first version but DDE is an exception.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
Well, as Pete and briefly touched on, it would avoid having to deal with
the (already/soon-to-be) obsolete DDE (Dynamic Data Exchange) and DDV
(Dynamic Data Validation) curently in use by MFC.
But yes, it's use, from a practical viewpoint, is limited. Limited but
robust. As it is, I save and load settings in a binary file. As the project
amasses Information, more such files will emerge. They cannot be
"nornalized" (look up the term as it applies to databases), being loose
files. So apart from being the inevitable future, more robust, and
normalizable it's "Just The Way These Things Are Done."
About normalization, imagine you have 10 contacts, all named "Smith". In a
database you'd be able to create a SURNAME table where "Smith" only occurs
once but have a unique ID. Other Places where you would write Smith you use
the ID instead, thus sacrifizing a little lookup time for space. A rather
contrived example, I admit, but there....
Regards
On Wednesday, January 2, 2019, Ted Matavka nmatavka@users.sourceforge.net
wrote:
Gents:
Could someone kindly explain to me, ideally in words of three syllables or
fewer, precisely to what end we need a relational database system? Please
don't misconstrue this as me being belligerent, or "not a team player"; if
you think we need it, we need it.
The only niche for it that I could possibly see is to run the personal
information manager/"address book"/contact list. If I'm correct (for
once), I think it'd be a reduplication of effort that'd be mighty hard to
justify. Keep in mind that there are billions and billions of
subtly-different, mutually-incompatible, yet tightly-integrated personal
information managers out there. Wouldn't it be better to focus our efforts
PIM-wise on something like, say, interoperability?
Think about it for a moment; I think it'd be just dandy if we could share a
PIM with Windows as a whole. Not to mention the space and effort we'd save.
Again, if I'm wildly off base, just ignore my ramblings.
On Tue, 1 Jan 2019 at 11:28, Soren Bro sbrothy@users.sourceforge.net
wrote:
I'm hearing you'd loathe to see DDE in there anywhere.
Missing a proper RDBMS though, I'm afraid we will have to endure DDE for
the time being. It's a select few places though and, in no way pervasive.
Due to the time with which to IKEA this together we'll just have to live
with this for starters.
I know it's an insanely geeky thing to say, but I miss the power of a
virtual CListCtrl hooked up to a database to do proper bulkrow fetching.
Also, I know there's no Iove lost between you and Boost, but I am, at
least, pulling in the library that does REGEXes. It's mostly for demo
purporses "validating" an email.
I happen to know, from previous experience, that there is (was?) no
standardised way of doing this, but hopefully we can agree that there are a
couple of formats that are downright wrong.
Regards.
It is a fre select Places though sand, as Duch, Can be
On Tuesday, January 1, 2019, Pete Maclean
petemaclean@users.sourceforge.net
wrote:
I agree that DDE is getting seriously obsolete and it is one thing I would
definitely replace. Mostly if something can be still made to work I would
opt to keep it at least for the first version but DDE is an exception.
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
I have negligible knowledge/experience of DBMSes so am not able to offer much input on this matter. I would just note that of the many email clients I have worked with, none has used an RDBMS. Well, unless Outlook's PST ranks as an RDBMS -- it is not clear to me if it does or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I'm back on track, the first thing I will do is to finish the I18n of
the porperties,
Boring but has to be done,
Regards,
Finished with that so far and, just as importantly, I've established a
pattern to be followed, in the future.
To make it easy on myself, I've decided that settings will validate and
change when an individuel value is changed, or defcused, making it easy
changing colour (to, say, yellow or red on incorrect settings, say: obvious
incorrect e-mail etc...
The save button will thus merely commit changes to disk.
Regards.
On Monday, December 31, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
I'm also working on making the Mail Detail window auto-open when creating
or opening a new or saved document (email). (They're really "drafts" but
their extension is .eml.)
At least the first time. This should really be an option and thus be part
of the settings too.
There's only 1 Mail Detail view, but each document has a GUID as ID.
This way multiple documents can be open yet still share the same 1 and only
Mail Detail CDockablePane.
Regards
On Tuesday, January 1, 2019, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
I've extended the menu to give you an idea of how it will look. I would
like the splash-screen to fade in and out. Jut for kicks. This may leave me
with precious Little Time for your recognisable toolbar, but you can't have
it all.
And bear in mind that it is a prototype, GUI only kind-of-thing. It is an
orderly thing though.
Should I mention a short-coming or two it is that it is my belief that
DoDataExchange is getting obsolete and that OLE isn't Property thought in
or out.
Regards.
On Tuesday, January 1, 2019, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
I agree that DDE is getting seriously obsolete and it is one thing I would definitely replace. Mostly if something can be still made to work I would opt to keep it at least for the first version but DDE is an exception.
I'm hearing you'd loathe to see DDE in there anywhere.
Missing a proper RDBMS though, I'm afraid we will have to endure DDE for
the time being. It's a select few places though and, in no way pervasive.
Due to the time with which to IKEA this together we'll just have to live
with this for starters.
I know it's an insanely geeky thing to say, but I miss the power of a
virtual CListCtrl hooked up to a database to do proper bulkrow fetching.
Also, I know there's no Iove lost between you and Boost, but I am, at
least, pulling in the library that does REGEXes. It's mostly for demo
purporses "validating" an email.
I happen to know, from previous experience, that there is (was?) no
standardised way of doing this, but hopefully we can agree that there are a
couple of formats that are downright wrong.
Regards.
It is a fre select Places though sand, as Duch, Can be
On Tuesday, January 1, 2019, Pete Maclean petemaclean@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Gents:
Could someone kindly explain to me, ideally in words of three syllables or
fewer, precisely to what end we need a relational database system? Please
don't misconstrue this as me being belligerent, or "not a team player"; if
you think we need it, we need it.
The only niche for it that I could possibly see is to run the personal
information manager/"address book"/contact list. If I'm correct (for
once), I think it'd be a reduplication of effort that'd be mighty hard to
justify. Keep in mind that there are billions and billions of
subtly-different, mutually-incompatible, yet tightly-integrated personal
information managers out there. Wouldn't it be better to focus our efforts
PIM-wise on something like, say, interoperability?
Think about it for a moment; I think it'd be just dandy if we could share a
PIM with Windows as a whole. Not to mention the space and effort we'd save.
Again, if I'm wildly off base, just ignore my ramblings.
On Tue, 1 Jan 2019 at 11:28, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
Well, as Pete and briefly touched on, it would avoid having to deal with
the (already/soon-to-be) obsolete DDE (Dynamic Data Exchange) and DDV
(Dynamic Data Validation) curently in use by MFC.
But yes, it's use, from a practical viewpoint, is limited. Limited but
robust. As it is, I save and load settings in a binary file. As the project
amasses Information, more such files will emerge. They cannot be
"nornalized" (look up the term as it applies to databases), being loose
files. So apart from being the inevitable future, more robust, and
normalizable it's "Just The Way These Things Are Done."
About normalization, imagine you have 10 contacts, all named "Smith". In a
database you'd be able to create a SURNAME table where "Smith" only occurs
once but have a unique ID. Other Places where you would write Smith you use
the ID instead, thus sacrifizing a little lookup time for space. A rather
contrived example, I admit, but there....
Regards
On Wednesday, January 2, 2019, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
In brief, although there's extra work involved, I´d rather write these
values to a database than to a binary file.
There also the inherent ability to make statistical analysis.
But for now it´s too much extra work for too little gain, This is supposed
to be a proof of concept after all.
Regards.
On Wed, Jan 2, 2019 at 10:25 AM Soren Bro sbrothy@users.sourceforge.net
wrote:
I have negligible knowledge/experience of DBMSes so am not able to offer much input on this matter. I would just note that of the many email clients I have worked with, none has used an RDBMS. Well, unless Outlook's PST ranks as an RDBMS -- it is not clear to me if it does or not.