From where do you imagine the toolbars will be sourced? Will it be a long strip, as in Eudora, or individual .ICO/JPG/PNG's? Individual icons would in my opinion be best.
Also, why are we talking about 16x16/32x32 icons, when modern displays can easily handle 32x32/48x48/64x64 icons?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From where do you imagine the toolbars will be sourced? Will it be a long
strip, as in Eudora, or individual .ICO/JPG/PNG's? Individual icons would
in my opinion be best.
Also, why are we talking about 16x16/32x32 icons, when modern displays can
easily handle 32x32/48x48/64x64 icons?
From where do you imagine the toolbars will be sourced? Will it be a long
strip, as in Eudora, or individual .ICO/JPG/PNG's? Individual icons would
in my opinion be best.
Also, why are we talking about 16x16/32x32 icons, when modern displays
can easily handle 32x32/48x48/64x64 icons?
From where do you imagine the toolbars will be sourced? Will it be a
long strip, as in Eudora, or individual .ICO/JPG/PNG's? Individual icons
would in my opinion be best.
Also, why are we talking about 16x16/32x32 icons, when modern displays
can easily handle 32x32/48x48/64x64 icons?
Boys, boys....
please don't stray too far from Eudora's current costmetics including the icons. Sure, make the icons higher rez but is it really necessary to change much in this area? In my 26 years of using Eudora, I don't recall having many icon complaints including how they're displayed/customized. I have all my displays configured as 1980x1080 with large Eudora icons and large text.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It´s just that I´m investigating whether we can use the built-in Send Mail
support in the CDocument class. This comes for free, but some OLE server
object/client data has to move back and forth between the two if we dont
to make Microsoft handle it all. I think this was what puzzled Mr Mclean:
What was my thoughts as to what could be done.which ´handn´t already had
been tried...
Boys, boys....
please don't stray too far from Eudora's current costmetics including the
icons. Sure, make the icons higher rez but is it really necessary to change
much in this area? In my 26 years of using Eudora, I don't recall having
many icon complaints including how they're displayed/customized. I have all
my displays configured as 1980x1080 with large Eudora icons and large text.
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens This
complete Outlook-alike client. Bringing data to and from it seems to be a
task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens
This complete Outlook-alike client. Bringing data to and from it seems to
be a task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Fun fact: You'd expect this to only work if Outlook is installed. But I
haven't, and it works anyway.
Regards.
On Tuesday, December 4, 2018, sbrothy@gmail.com wrote:
(AFK)
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens
This complete Outlook-alike client. Bringing data to and from it seems to
be a task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Now, I'm not the e-mail guru here but, am I correct in assuming that the
backbone of such an e-mail client would be an SMTP server?
Regards
On Tue, Dec 4, 2018 at 5:26 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
(AFK)
Fun fact: You'd expect this to only work if Outlook is installed. But I
haven't, and it works anyway.
Regards.
On Tuesday, December 4, 2018, sbrothy@gmail.com wrote:
(AFK)
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens
This complete Outlook-alike client. Bringing data to and from it seems to
be a task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Regards.
Søren
On Tuesday, December 4, 2018, Pete Maclean petemaclean@users.sourceforge
.net petemaclean@users.sourceforge.net wrote:
Now Mr. Maclean is even more puzzled! We are not building a MAPI client
so why would we want to use this support in MFC for sending mail?
Object Linking and Embedding should be able to move data back and forth
between these apps. I´m not an expert in it but I have a feeling h'that I´m
about to be.
Now, I'm not the e-mail guru here but, am I correct in assuming that the
backbone of such an e-mail client would be an SMTP server?
Regards
On Tue, Dec 4, 2018 at 5:26 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
(AFK)
Fun fact: You'd expect this to only work if Outlook is installed. But I
haven't, and it works anyway.
Regards.
On Tuesday, December 4, 2018, sbrothy@gmail.com wrote:
(AFK)
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the
samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens
This complete Outlook-alike client. Bringing data to and from it seems to
be a task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Regards.
Søren
On Tuesday, December 4, 2018, Pete Maclean petemaclean@users.sourceforge
.net petemaclean@users.sourceforge.net wrote:
Now Mr. Maclean is even more puzzled! We are not building a MAPI client
so why would we want to use this support in MFC for sending mail?
Object Linking and Embedding should be able to move data back and forth
between these apps. I´m not an expert in it but I have a feeling h'that I´m
about to be.
Now, I'm not the e-mail guru here but, am I correct in assuming that the
backbone of such an e-mail client would be an SMTP server?
Regards
On Tue, Dec 4, 2018 at 5:26 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
(AFK)
Fun fact: You'd expect this to only work if Outlook is installed. But I
haven't, and it works anyway.
Regards.
On Tuesday, December 4, 2018, sbrothy@gmail.com wrote:
(AFK)
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the
samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens
This complete Outlook-alike client. Bringing data to and from it seems to
be a task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Regards.
Søren
On Tuesday, December 4, 2018, Pete Maclean petemaclean@users.sourceforge
.net petemaclean@users.sourceforge.net wrote:
Now Mr. Maclean is even more puzzled! We are not building a MAPI client
so why would we want to use this support in MFC for sending mail?
Object Linking and Embedding should be able to move data back and forth
between these apps. I´m not an expert in it but I have a feeling h'that I´m
about to be.
Now, I'm not the e-mail guru here but, am I correct in assuming that the
backbone of such an e-mail client would be an SMTP server?
Regards
On Tue, Dec 4, 2018 at 5:26 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
(AFK)
Fun fact: You'd expect this to only work if Outlook is installed. But I
haven't, and it works anyway.
Regards.
On Tuesday, December 4, 2018, sbrothy@gmail.com wrote:
(AFK)
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the
samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens
This complete Outlook-alike client. Bringing data to and from it seems
to
be a task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Regards.
Søren
On Tuesday, December 4, 2018, Pete Maclean petemaclean@users.sourceforge
.net petemaclean@users.sourceforge.net wrote:
Now Mr. Maclean is even more puzzled! We are not building a MAPI client
so why would we want to use this support in MFC for sending mail?
By application, do you mean your homemade HERMES Mail frontend, the original Eudora frontend (eudora.exe), or HERMES Mail as a notional "complete package"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have taken a while to respond about this because I have been traveling. And the answer is no, we do not need nor want an SMTP server. I believe I told you some time ago that I once created a product that worked as an add-on to Eudora that, in part, gave it an SMTP server. And, despite one glowing review, it sold about 3 copies. I thought it a clever idea (and still do) but it is clearly not something the world wants. And, more fundamentally, even if we wanted to give Hermes every last little exotic feature we could dream up, this would be one of the last to consider.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm more or less dedicating my entire free time to this project as of now!.
I'm on disability pension, and have scrapped some of my more time-consuming
"social contracts", so it's quite a lot of time. it's starting to get
personal now. I have some basic problems which shouldn't be problems at
all, but here we are.
I'm stuck with some really embarrassing problems regarding the underlying
CDocument class and some unresponsive MESSAGE_MAPS.
I'm trying to create a complete GUI from scratch (Simple MAPI is already
working, but it's a choice, not an unavoidable feature. It's there. Use
it or dont.), and then I will insert the healthy DLLs from the old project.
The stuff Mr. Maclean painstaikingly made work. if not I would disrespect
his efforts to a degree i wouldn't want to consider seriously.
QCTILS.DLL for one, but there are more.
Is is going to work! If you like the result or not I of course cannot
say, I don't have a crystal ball. Time will have to tell.
Regards,
S. Bro
"You cannot make an omelette without crushing dozens of eggs beneath your
steelboot and publicly disemboweling the hens that laid them as a warning
to others."
---- General Tarquin, Order of the Stick (Webcomic).
This is driving me up the wall. Im supposed to be the resident MFC "expert"
and I cannot get a simple button to respond even though Ive been using all
day wrestling with this problem; to the point of asking as question on the
MSDN forums (where, incidentally, I found a a bunch of other questions I
asked back in 09 regarding C# and Silverlight, Im having fun here.
Simple MAPI works though. But who cares about that?!
I'm more or less dedicating my entire free time to this project as of now!.
I'm on disability pension, and have scrapped some of my more time-consuming
"social contracts", so it's quite a lot of time. it's starting to get
personal now. I have some basic problems which shouldn't be problems at
all, but here we are.
I'm stuck with some really embarrassing problems regarding the underlying
CDocument class and some unresponsive MESSAGE_MAPS.
I'm trying to create a complete GUI from scratch (Simple MAPI is already
working, but it's a choice, not an unavoidable feature. It's there. Use
it or dont.), and then I will insert the healthy DLLs from the old project.
The stuff Mr. Maclean painstaikingly made work. if not I would disrespect
his efforts to a degree i wouldn't want to consider seriously.
QCTILS.DLL for one, but there are more.
Is is going to work! If you like the result or not I of course cannot
say, I don't have a crystal ball. Time will have to tell.
Regards,
S. Bro
"You cannot make an omelette without crushing dozens of eggs beneath your
steelboot and publicly disemboweling the hens that laid them as a warning
to others."
---- General Tarquin, Order of the Stick (Webcomic).
I guess where I was going with this was to retain Eudora´s GUI and then
handle anything at all it in the background by whatever tools are
available. DLLs from the original codebase would plug right in. I even have
some updates to the GUI. See attached files.
The address window is a dockkable window. It can dock in all 4 sides or be
turned off , as here. A GUID connects them.
Boys, boys....
please don't stray too far from Eudora's current costmetics including the
icons. Sure, make the icons higher rez but is it really necessary to change
much in this area? In >>my 26 years of using Eudora, I don't recall having
many icon complaints including how they're displayed/customized. I have all
my displays configured as 1980x1080 >>with large Eudora icons and large
text.
Please dont worry about this. Im told we have the original icons. If
nothing else, for higher resolution, we can ask the resident art expert I
hear about to give them an update.
Boys, boys....
please don't stray too far from Eudora's current costmetics including the
icons. Sure, make the icons higher rez but is it really necessary to change
much in this area? In my 26 years of using Eudora, I don't recall having
many icon complaints including how they're displayed/customized. I have all
my displays configured as 1980x1080 with large Eudora icons and large text.
From where do you imagine the toolbars will be sourced? Will it be a long strip, as in Eudora, or individual .ICO/JPG/PNG's? Individual icons would in my opinion be best.
Also, why are we talking about 16x16/32x32 icons, when modern displays can easily handle 32x32/48x48/64x64 icons?
(AFK)
No particular reason other than the ones on my screen seems really small.
Should I guess I'd say 16x16. :)
It can be set through. You're right about that.
Regards
On Wednesday, November 21, 2018, Ted Matavka nmatavka@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
Or maybe they are in fact 32x32, my resolution is just really high.
Regards
On Wednesday, November 21, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
Anyway, HICON is a data object which is simultaneously all of the above.
They still need to be drawn individually though.
Regards
On Wednesday, November 21, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
Boys, boys....
please don't stray too far from Eudora's current costmetics including the icons. Sure, make the icons higher rez but is it really necessary to change much in this area? In my 26 years of using Eudora, I don't recall having many icon complaints including how they're displayed/customized. I have all my displays configured as 1980x1080 with large Eudora icons and large text.
It´s just that I´m investigating whether we can use the built-in Send Mail
support in the CDocument class. This comes for free, but some OLE server
object/client data has to move back and forth between the two if we dont
to make Microsoft handle it all. I think this was what puzzled Mr Mclean:
What was my thoughts as to what could be done.which ´handn´t already had
been tried...
Regards.
S. Bro
On Sun, Dec 2, 2018 at 5:02 AM Walt Stagner wstagner@users.sourceforge.net
wrote:
Now Mr. Maclean is even more puzzled! We are not building a MAPI client so why would we want to use this support in MFC for sending mail?
(AFK)
It's just an attempt to see how much we can get for "free". I haven't
locked on to anything yet. It's just that a fully functioning Outlook
Ekspress-like client is build into the samples (Well not really the samples
per se, but it's there, Build in to MFC.). To preserve the look&feel of
Eudora will take some work. Although much less work than starting from
scratch. See:
CDocument::OnFileSendMail ()
This command, which can of course be triggered programmatically, opens This
complete Outlook-alike client. Bringing data to and from it seems to be a
task for COleDocument, or OLE generally.
I'm not lobbying for MAPI per se, but if its there so it might come in
handy.
Regards.
Søren
On Tuesday, December 4, 2018, Pete Maclean petemaclean@users. sourceforge.net wrote:
--
Søren Bro Thygesen
(AFK)
Fun fact: You'd expect this to only work if Outlook is installed. But I
haven't, and it works anyway.
Regards.
On Tuesday, December 4, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
(AFK)
Now, I'm not the e-mail guru here but, am I correct in assuming that the
backbone of such an e-mail client would be an SMTP server?
Regards
On Tue, Dec 4, 2018 at 5:26 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
The magic mail client I was talking about.
Regards.
On Thu, Dec 6, 2018 at 11:46 AM Soren Bro sbrothy@users.sourceforge.net
wrote:
Object Linking and Embedding should be able to move data back and forth
between these apps. I´m not an expert in it but I have a feeling h'that I´m
about to be.
Regards.
On Thu, Dec 6, 2018 at 8:29 PM sbrothy@gmail.com wrote:
This may be MAPI but, if we roll our own mail server (SMTP?) I´m pretty
sure we´re gonna call the shots.
Regards.
On Thu, Dec 6, 2018 at 8:32 PM sbrothy@gmail.com wrote:
Problem is, this application is already pretty big. Organized to be sure
but, still pretty big.
Regards.
On Thu, Dec 6, 2018 at 8:35 PM sbrothy@gmail.com wrote:
By application, do you mean your homemade HERMES Mail frontend, the original Eudora frontend (eudora.exe), or HERMES Mail as a notional "complete package"?
I have taken a while to respond about this because I have been traveling. And the answer is no, we do not need nor want an SMTP server. I believe I told you some time ago that I once created a product that worked as an add-on to Eudora that, in part, gave it an SMTP server. And, despite one glowing review, it sold about 3 copies. I thought it a clever idea (and still do) but it is clearly not something the world wants. And, more fundamentally, even if we wanted to give Hermes every last little exotic feature we could dream up, this would be one of the last to consider.
Don't we have an SMTP module somewhere within the Eudora code?
Yes, we do. It is Eudora\sendmail.cpp . (Which I would rename to avoid confusion.)
I'm more or less dedicating my entire free time to this project as of now!.
I'm on disability pension, and have scrapped some of my more time-consuming
"social contracts", so it's quite a lot of time. it's starting to get
personal now. I have some basic problems which shouldn't be problems at
all, but here we are.
I'm stuck with some really embarrassing problems regarding the underlying
CDocument class and some unresponsive MESSAGE_MAPS.
I'm trying to create a complete GUI from scratch (Simple MAPI is already
working, but it's a choice, not an unavoidable feature. It's there. Use
it or dont.), and then I will insert the healthy DLLs from the old project.
The stuff Mr. Maclean painstaikingly made work. if not I would disrespect
his efforts to a degree i wouldn't want to consider seriously.
QCTILS.DLL for one, but there are more.
Is is going to work! If you like the result or not I of course cannot
say, I don't have a crystal ball. Time will have to tell.
Regards,
S. Bro
"You cannot make an omelette without crushing dozens of eggs beneath your
steelboot and publicly disemboweling the hens that laid them as a warning
to others."
---- General Tarquin, Order of the Stick (Webcomic).
On Sat, Dec 15, 2018 at 6:43 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
This is driving me up the wall. Im supposed to be the resident MFC "expert"
and I cannot get a simple button to respond even though Ive been using all
day wrestling with this problem; to the point of asking as question on the
MSDN forums (where, incidentally, I found a a bunch of other questions I
asked back in 09 regarding C# and Silverlight, Im having fun here.
Simple MAPI works though. But who cares about that?!
Regards.
Yours Truly.
On Sat, Dec 15, 2018 at 7:52 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I guess where I was going with this was to retain Eudora´s GUI and then
handle anything at all it in the background by whatever tools are
available. DLLs from the original codebase would plug right in. I even have
some updates to the GUI. See attached files.
The address window is a dockkable window. It can dock in all 4 sides or be
turned off , as here. A GUID connects them.
On Thu, Dec 6, 2018 at 8:29 PM sbrothy@gmail.com wrote:
That would indeed be the case. SMTP and IMAP. Everything else is, as they say, gravy.
Please dont worry about this. Im told we have the original icons. If
nothing else, for higher resolution, we can ask the resident art expert I
hear about to give them an update.
Regards.
On Sun, Dec 2, 2018 at 5:02 AM Walt Stagner wstagner@users.sourceforge.net
wrote:
As long as Hermes retains the look/feel/operation of Eudora I think we'll all be satsified.
As a long time Eudora user since 1999, I think, I have very much appreciated these features of Eudora:
I only have these issues:
That's it. Fix #2 and I need nothing more from Eudora.