version of the these classes as well. Both of which may be superior to both
COleVariant and CComVariant.
Again, although Mr McLean has expressed a dislike of the boost API, I'm
gonna pull it in anyway. There is a bimap [sic!] in there I want. Also,
boost implement REGEXes. I'm just sure we're gonna need that.
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
I must admit I was beginning to panic a little with regards to time, but it
now seems I'm really on the right track....
Regards,
Søren .
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
Regards.
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
Wow, I found an undocumented gem that does the job beautifully:
I'm still having some issues storing bespoke data structures in CComVariant.
LOGFONT structure.
COLORREF.
Because it's COM it looks more complicated than it actually is. This is the
last serializable data type problem and I'll solve it soon, If not by
copy/pasta then by honest to God RTFM.
On Mon, Jan 14, 2019 at 2:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I must admit I was beginning to panic a little with regards to time, but it
now seems I'm really on the right track....
Regards,
Søren .
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
Regards.
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
Wow, I found an undocumented gem that does the job beautifully:
COM and ATL. In the meantime I've got tons of things to do. Maybe if the
code got uploaded to a proper repository someone would be able to point out
where I'm meandering off the beaten path.
I'm still having some issues storing bespoke data structures in
CComVariant.
LOGFONT structure.
COLORREF.
Because it's COM it looks more complicated than it actually is. This is
the last serializable data type problem and I'll solve it soon, If not by
copy/pasta then by honest to God RTFM.
On Mon, Jan 14, 2019 at 2:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I must admit I was beginning to panic a little with regards to time, but
it
now seems I'm really on the right track....
Regards,
Søren .
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
Regards.
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
Wow, I found an undocumented gem that does the job beautifully:
COM and ATL. In the meantime I've got tons of things to do. Maybe if the
code got uploaded to a proper repository someone would be able to point out
where I'm meandering off the beaten path.
Regards.
On Mon, Jan 14, 2019 at 9:07 PM sbrothy@gmail.com wrote:
I'm still having some issues storing bespoke data structures in
CComVariant.
LOGFONT structure.
COLORREF.
Because it's COM it looks more complicated than it actually is. This is
the last serializable data type problem and I'll solve it soon, If not by
copy/pasta then by honest to God RTFM.
Regards.
On Mon, Jan 14, 2019 at 9:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
On Mon, Jan 14, 2019 at 2:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I must admit I was beginning to panic a little with regards to time, but
it
now seems I'm really on the right track....
Regards,
Søren .
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
Regards.
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
Wow, I found an undocumented gem that does the job beautifully:
--
----- 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 would gladly have done so but, as I've been forced to start over more
than a dozen times, creating the project from scratch using the AppWizard,
it hasn't really been possible.
What I have now is a bunch of projects, each containing code that solves
specific problems. In the end I need to re-create the project and combine
the features from them all and then I can put it in a repository.
Right now I need the freedom to start using the AppWizard and then add code
from the various projects.
Like for instance, I have i18n in one. The persistence of settings in
another. A menu that resembles Eudora's in a third. A CRichEditView
document in a fourth and the single address info vis-a-vis multiple
documents in a fifth.
Problem is, if I combine them prematurely I'll probably get a shitload of
errors. I'm nearing that point though.
Also, because of VS setup problems I'm forced to link MFC statically where
in reality I'd much prefer shared.
I'm getting there though. One of the reasons for my problems is that I'd
like to think OLE automation into it. Especially if we want to use this
inbuilt MAPI Outlook clone.
Maybe we wont but it wont hurt preparing for the posibillity. If our app is
a full-fledged OLE client/server container, it'll be able to talk
seemlessly with other M$ programs like for instance Exchange Server or
Outlook proper.
Yes, precisely. I hope you've created a repository locally!
On Mon, 14 Jan 2019 at 15:10, Soren Bro sbrothy@users.sourceforge.net
wrote:
COM and ATL. In the meantime I've got tons of things to do. Maybe if the
code got uploaded to a proper repository someone would be able to point out
where I'm meandering off the beaten path.
Regards.
On Mon, Jan 14, 2019 at 9:07 PM sbrothy@gmail.com wrote:
I'm still having some issues storing bespoke data structures in
CComVariant.
LOGFONT structure.
COLORREF.
Because it's COM it looks more complicated than it actually is. This is
the last serializable data type problem and I'll solve it soon, If not by
copy/pasta then by honest to God RTFM.
Regards.
On Mon, Jan 14, 2019 at 9:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
On Mon, Jan 14, 2019 at 2:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I must admit I was beginning to panic a little with regards to time, but
it
now seems I'm really on the right track....
Regards,
Søren .
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
Regards.
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
Wow, I found an undocumented gem that does the job beautifully:
--
----- 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 would gladly have done so but, as I've been forced to start over more
than a dozen times, creating the project from scratch using the AppWizard,
it hasn't really been possible.
What I have now is a bunch of projects, each containing code that solves
specific problems. In the end I need to re-create the project and combine
the features from them all and then I can put it in a repository.
Right now I need the freedom to start using the AppWizard and then add code
from the various projects.
Like for instance, I have i18n in one. The persistence of settings in
another. A menu that resembles Eudora's in a third. A CRichEditView
document in a fourth and the single address info vis-a-vis multiple
documents in a fifth.
Problem is, if I combine them prematurely I'll probably get a shitload of
errors. I'm nearing that point though.
Also, because of VS setup problems I'm forced to link MFC statically where
in reality I'd much prefer shared.
I'm getting there though. One of the reasons for my problems is that I'd
like to think OLE automation into it. Especially if we want to use this
inbuilt MAPI Outlook clone.
Maybe we wont but it wont hurt preparing for the posibillity. If our app is
a full-fledged OLE client/server container, it'll be able to talk
seemlessly with other M$ programs like for instance Exchange Server or
Outlook proper.
COM and ATL. In the meantime I've got tons of things to do. Maybe if the
code got uploaded to a proper repository someone would be able to point out
where I'm meandering off the beaten path.
I'm still having some issues storing bespoke data structures in
CComVariant.
LOGFONT structure.
COLORREF.
Because it's COM it looks more complicated than it actually is. This is
the last serializable data type problem and I'll solve it soon, If not by
copy/pasta then by honest to God RTFM.
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
--
----- 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!)
------------------------------
All the union variant datatypes I've been speaking about store strings as
BSTRs.
These are a nightmare to handle, cast and copy as they require attention to
memory issues.
I want them translated into UNICODE (or possibly OLECHARs for automation
purposes). Using multibyte doesn't make it any easier.
I'll use this thread to gather relevant information starting with this
cornucopia of Information.
https://www.codeproject.com/Articles/3004/%2FArticles%2F3004%2FThe-Complete-Guide-to-C-Strings-Part-II-String-Wra
More will follow, I'm sure.
Regards,
Søren
--
Søren Bro Thygesen
In the interest of completion there's a
std::variant and a
boost::variant
version of the these classes as well. Both of which may be superior to both
COleVariant and CComVariant.
Again, although Mr McLean has expressed a dislike of the boost API, I'm
gonna pull it in anyway. There is a bimap [sic!] in there I want. Also,
boost implement REGEXes. I'm just sure we're gonna need that.
R
On Sunday, January 13, 2019, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
If I have given you the impression that I do not like Boost then I have done so mistakenly. I have absolutely nothing against it.
My bad then. I just seem to remember you didn´t like it, It might just have
been a wish of yours to KISS. ;)
Let´s not explore the methaphorical implications of that acronym. :P
Regards,
Søren
On Sun, Jan 13, 2019 at 6:56 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
https://blogs.msdn.microsoft.com/ericlippert/2003/09/12/erics-complete-guide-to-bstr-semantics/
On Sunday, January 13, 2019, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
Wow, I found an undocumented gem that does the job beautifully:
[...]
void CHermesSettings::Serialize(CArchive& archive)
{
CObject::Serialize(archive);
CArchiveStream pStream(&archive);
if (archive.IsStoring())
{
m_b3DLook.WriteToStream(&pStream);
m_strCaption.WriteToStream(&pStream);
}
else
{
m_b3DLook.ReadFromStream(&pStream);
m_strCaption.ReadFromStream(&pStream);
}
}
[...]
This seems to work consistently. For the loading and saving at least. Now I
just need to pull the BSTRs out of there...
Regards,
Søren
On Mon, Jan 14, 2019 at 10:42 AM Soren Bro sbrothy@users.sourceforge.net
wrote:
I've achived that too. I'm now in the progress of adding a bunch of
settings that will be serializable ("persistent", if you prefer). Some
still has some child issues. The font structure for instance. Some are
there only for show (like spincontrolled window size).
There's a well-established pattern for adding new settings now though. I
will spell it out in the code for the time being.
When I've added enough different settings for proof-of-concept, I'll
continue by implementing my "one mail address window vis-a-vis multiple
documents (emails) idea.
I have a lot of code spread out over multiple projects that I will put
together. Hopefully it'll begin to look like something tangible.
For the actual mail edit window the sample WORDPAD might be worth taking a
look at.
I'm not sure a centralized font setting is a good idea. After all, I might
want to use one font in one email and another in another...
Regards.
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
I must admit I was beginning to panic a little with regards to time, but it
now seems I'm really on the right track....
Regards,
Søren .
On Monday, January 14, 2019, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
http://www.prowaretech.com/archive/ATL/ComGuide.htm
On Mon, Jan 14, 2019 at 2:45 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I'm still having some issues storing bespoke data structures in CComVariant.
LOGFONT structure.
COLORREF.
Because it's COM it looks more complicated than it actually is. This is the
last serializable data type problem and I'll solve it soon, If not by
copy/pasta then by honest to God RTFM.
Regards.
On Mon, Jan 14, 2019 at 9:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
COM and ATL. In the meantime I've got tons of things to do. Maybe if the
code got uploaded to a proper repository someone would be able to point out
where I'm meandering off the beaten path.
Regards.
On Mon, Jan 14, 2019 at 9:07 PM sbrothy@gmail.com wrote:
Yes, precisely. I hope you've created a repository locally!
On Mon, 14 Jan 2019 at 15:10, 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!)
I would gladly have done so but, as I've been forced to start over more
than a dozen times, creating the project from scratch using the AppWizard,
it hasn't really been possible.
What I have now is a bunch of projects, each containing code that solves
specific problems. In the end I need to re-create the project and combine
the features from them all and then I can put it in a repository.
Right now I need the freedom to start using the AppWizard and then add code
from the various projects.
Like for instance, I have i18n in one. The persistence of settings in
another. A menu that resembles Eudora's in a third. A CRichEditView
document in a fourth and the single address info vis-a-vis multiple
documents in a fifth.
Problem is, if I combine them prematurely I'll probably get a shitload of
errors. I'm nearing that point though.
Also, because of VS setup problems I'm forced to link MFC statically where
in reality I'd much prefer shared.
I'm getting there though. One of the reasons for my problems is that I'd
like to think OLE automation into it. Especially if we want to use this
inbuilt MAPI Outlook clone.
Maybe we wont but it wont hurt preparing for the posibillity. If our app is
a full-fledged OLE client/server container, it'll be able to talk
seemlessly with other M$ programs like for instance Exchange Server or
Outlook proper.
Regards,
Søren
On Tuesday, January 15, 2019, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
I would gladly have done so but, as I've been forced to start over more
than a dozen times, creating the project from scratch using the AppWizard,
it hasn't really been possible.
What I have now is a bunch of projects, each containing code that solves
specific problems. In the end I need to re-create the project and combine
the features from them all and then I can put it in a repository.
Right now I need the freedom to start using the AppWizard and then add code
from the various projects.
Like for instance, I have i18n in one. The persistence of settings in
another. A menu that resembles Eudora's in a third. A CRichEditView
document in a fourth and the single address info vis-a-vis multiple
documents in a fifth.
Problem is, if I combine them prematurely I'll probably get a shitload of
errors. I'm nearing that point though.
Also, because of VS setup problems I'm forced to link MFC statically where
in reality I'd much prefer shared.
I'm getting there though. One of the reasons for my problems is that I'd
like to think OLE automation into it. Especially if we want to use this
inbuilt MAPI Outlook clone.
Maybe we wont but it wont hurt preparing for the posibillity. If our app is
a full-fledged OLE client/server container, it'll be able to talk
seemlessly with other M$ programs like for instance Exchange Server or
Outlook proper.
Regards,
Søren
On Tuesday, January 15, 2019, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Technical detail- future documentation.
Sent from <wbr></wbr>sourceforge.net<wbr></wbr> because you indicated interest inhttps://sourceforge.net/p/hermesmail/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/