We can easily enlarge the already exiting icons programmatically, on the
fly,^ but, without custom larger icons they will probably end up as blurry
copies though. The important lesson here is that it's possible, and pretty
easy at that. it may require some extra artwork. As far as I remember icons
are build so the same image contains the different sizes. So if someone has
an artistic st real se should be set....
The good news is that the icons I remember seeing in Eudora was already
big. Making Them smaller should be a breeze. I'll have a look.....m
OK......we'll give you feedback on this when we start using the program.
Is the first release going to include an auto import of Eudora's accounts & settings?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first "release" will be an empty GUI shell. I complicated some things
for myself deciding to have a dedicated (dockable/floatable/closable)
window for the "to", "from", "subject". "Cc", "bcc" and attachments. This
way, you can write an email using the entire screen. Much like a text
editor really. But with an MDI app this makes for some hard and/or
difficult decisions. I still like the idea though. And I'm nearly there.
What I'm fighting with right now is exactly the various ways this window
must be updated based on an ID (GUID) in each document.
All the data will still reside in the document. Only the display will be
handled by this window.
But for instance, what will this window display if there are e-mail text
windows on-screen, none of which are active? Decisions like that....
OK......we'll give you feedback on this when we start using the program.
Is the first release going to include an auto import of Eudora's accounts
& settings?
OK......we'll give you feedback on this when we start using the program.
Is the first release going to include an auto import of Eudora's accounts
& settings?
First impressions mean something.
I'd suggest getting the Hermes look to actually
resemble Eudora on first beta.
The more it resembles Eudora the more we (the audience) will embrace it and crave more!
Last edit: Walt Stagner 2019-02-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that´s first gonna happen on second beta, I've made a point out of
keeping the two projects apart initially.
I can copy the menu, even the toolbar but it will just be a bunch of empty
functions. Better we add the menu options and toolbar options when they
actually do something.
Youre gonna see something that doesnt resemble Eudora on first glance but I
promise you (and with McLean's promise regarding IMAP, we´ll be there in
no time at all.)
Especially with the DLLs from _Eudora. They're still good. At least the one
we have code for. Well even without the code, /DUMPBIN and GetProcAdress
was invented for reasons,
First impressions mean something.
I'd suggest getting the Hermes look to actually
resemble Eudora on first beta.
The more it resembles Eudora the more we (the audience) will embrace it
and crave more!
I have a hard time understanding the "can only be set from the "ini-file
thingie". The options menu in Eudora looks pretty complete, But again
there will be no reaons to go around Hermers to make a change to a setting.
Why you've been puttinh up with this is really a little beyond me. How can
a program have options that are not configurable from within the program
itself? I'm seriously mystified.
Yes, that´s first gonna happen on second beta, I've made a point out of
keeping the two projects apart initially.
I can copy the menu, even the toolbar but it will just be a bunch of empty
functions. Better we add the menu options and toolbar options when they
actually do something.
Youre gonna see something that doesnt resemble Eudora on first glance but I
promise you (and with McLean's promise regarding IMAP, we´ll be there in
no time at all.)
Especially with the DLLs from _Eudora. They're still good. At least the one
we have code for. Well even without the code, /DUMPBIN and GetProcAdress
was invented for reasons,
Regards.
Søren
On Tue, Feb 5, 2019 at 3:33 PM Walt Stagner wstagner@users.sourceforge.net
wrote:
First impressions mean something.
I'd suggest getting the Hermes look to actually
resemble Eudora on first beta.
The more it resembles Eudora the more we (the audience) will embrace it
and crave more!
How can a program have options that are not configurable from within the program
itself?
I do not mean to say that I consider this is a good idea but the thinking might be that some rarely needed options should be settable only by manual intervention to keep less-sophisticated users from hurting themselves (and raising support costs!) by changing settings that generally should not be changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a very significant matter. I had supposed all along until now that what we produce would not have and not need any import capability but would simply work in place. There certainly are aspects of the way Eudora stores things that could be improved and, as our software evolves, should be improved. However I see no reason to change such things from the outset. It would mean developing an import utility that, as I see it, should not be necessary. Why do the extra work? That is both the extra work of designing and implementing a new storage system and the extra work of writing an importer. Eudora's system is awkward in certain ways but it is nevertheless efficient and scalable. My Eudora has 4,474 mailboxes holding around 1 million messages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mr Maclean, please note that Mr Thygesen is referring to settings import,
rather than mailbox import; we're doing a new GUI, so all it should do is
find the Eudora AppData directory and parse the eudora.ini file or
whatever. Your messages will stay in the format they are/
This is a very significant matter. I had supposed all along until now that
what we produce would not have and not need any import capability but would
simply work in place. There certainly are aspects of the way Eudora stores
things that could be improved and, as our software evolves, should be
improved. However I see no reason to change such things from the outset. It
would mean developing an import utility that, as I see it, should not be
necessary. Why do the extra work? That is both the extra work of designing
and implementing a new storage system and the extra work of writing an
importer. Eudora's system is awkward in certain ways but it is nevertheless
efficient and scalable. My Eudora has 4,474 mailboxes holding around 1
million messages.
--
----- 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!)
Jesus Kristus! I can see why you're loyal to the old client. And I agree
that an import script would be more or less a waste of time. Yes. There're
a lot of settings but not any more than it can be done manually. The new
client store the settings in binary where XML would perhaps have been a
better choice.
Regarding the look and feel of Eudora's GUI please don't despair at first
look. We will quickly make it recognizable. Remember also though , that
we're making a tigerleap MFC-version wise. As such you should expect the
new GUI to be just that: New.
This is a very significant matter. I had supposed all along until now that
what we produce would not have and not need any import capability but would
simply work in place. There certainly are aspects of the way Eudora stores
things that could be improved and, as our software evolves, should be
improved. However I see no reason to change such things from the outset. It
would mean developing an import utility that, as I see it, should not be
necessary. Why do the extra work? That is both the extra work of designing
and implementing a new storage system and the extra work of writing an
importer. Eudora's system is awkward in certain ways but it is nevertheless
efficient and scalable. My Eudora has 4,474 mailboxes holding around 1
million messages.
Many Eudora users are, I believe, accustomed to editing their Eudora.ini files to change settings. As far as I know, in the case of a few rare options, doing so is the only way to make changes. So the idea of storing them in binary makes me uneasy. Well, even the idea of changing how they are stored in the first place makes me wonder. However if there is a complete way of viewing and editing all settings in the GUI then it should be okay.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've had bad luck trying to upload the "proof-of-concept" program I wrote
using Mercurial. I can pack it into a ZIP package and put it somewhere
complete with executable. I haven't really tried to make it look like
Eudora. I thought the better priority would be to make the things under the
hood work. Like actually sending a message. As I said I wrote myself into a
corner but I'm nearly in a sane place again.
As soon as we're more than one person on this we can make nice
splashscreens and toolbars. In my opnion though, as I think I've emphasised
numerous times, Making it send and receive a message is the hall - mark.
The stupid part is that, as you'll immediately see when you run the
application, a complete Microsoft Outlook clone is built into to the MFC
framework. So. Then. Why even do this?
I still think priority numero uno should be at least an SQL database "under
the hood". I call upon Mr MacLean to help me with this. I have a suspicion
he's the only one who understands what I mean when I'm talking about
"normalization" with respect to a database system design. We have a
Professor Emeritus from Northumbria University willing to help us with
this. Why the heck doesn't we go somewhere serious with the application?
And when I hear about the numnber of eamils involved. Millions?! WHAT THE
FUCK! (Pardon my French). But why didn't someone put a proper database
behind this monster before?
I dont' care about false news or spamming. I care about developing a
program that can do whatever people want. If that's what they want so be
it. Is just another front in another war I don't care about. I care about
the thing actually doing what we want. I basically want to play with LEGO.
Many Eudora users are, I believe, accustomed to editing their Eudora.ini
files to change settings. As far as I know, in the case of a few rare
options, doing so is the only way to make changes. So the idea of storing
them in binary makes me uneasy. Well, even the idea of changing how they
are stored in the first place makes me wonder. However if there is a
complete way of viewing and editing all settings in the GUI then it should
be okay.
Thanks to Eudora's statistics, I can tell you that at this moment I have 1,201,289 messages in my Eudora. And I feel sure that there will be plenty more users with over a million, perhaps some with several million.
I still think priority numero uno should be at least an SQL database "under
the hood". I call upon Mr MacLean to help me with this.
This is a bit embarrassing for me as a person who has worked with computers for nearly 50 years, who has taught Computer Science, and has considerable expertise in several areas (operating systems , embedded software, Internet protocols, etc.), but databases are a mystery to me. I have never actively avoided them but I have never worked with them and know almost nothing about them. I could not even begin to assess how useful or appropriate an SQL database would be in an email client. So, sorry, but I think I will not be able to help with this.
I am very inclined to trust your assertion that we should put a database under the hood but I would still like to hear a few concrete examples of how this would benefit the product. And, even if it is made priority numero uno, I still think strongly that it should be such a priority for and only for a second edition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The numbers alone should make it obvious. But it depends upon the the
design ofcourse. I need to know what you mean by "mailboxes". How many
tables should be in such a database? How are they related? I can see
"CONTACTS" and "MESSAGES" as tables immediately. With attributes like sent
or not. Subjects, threading and all. I'´m surprised you've come as long as
you have without relating to a "Relational" database. :)
The data should be in a relational database management system. The view?
Well, how do you want to look at it?
Thanks to Eudora's statistics, I can tell you that at this moment I have
1,201,289 messages in my Eudora. And I feel sure that there will be plenty
more users with over a million, perhaps some with several million.
I still think priority numero uno should be at least an SQL database "under
the hood". I call upon Mr MacLean to help me with this.
This is a bit embarrassing for me as a person who has worked with
computers for nearly 50 years, who has taught Computer Science, and has
considerable expertise in several areas (operating systems , embedded
software, Internet protocols, etc.), but databases are a mystery to me. I
have never actively avoided them but I have never worked with them and know
almost nothing about them. I could not even begin to assess how useful or
appropriate an SQL database would be in an email client. So, sorry, but I
think I will not be able to help with this.
I am very inclined to trust your assertion that we should put a database
under the hood but I would still like to hear a few concrete examples of
how this would benefit the product. And, even if it is made priority numero
uno, I still think strongly that it should be such a priority for and only
for a second edition.
But it depends upon the the design of course. I need to know what you mean by "mailboxes".
Eudora uses the term "mailbox" in a sense that it is not standard. In Eudora, a 'mailbox' is a named container for messages. In Outlook the same thing is called a 'folder' and, I think it is fair to say in general, this is what most people would call a 'folder'.
How many tables should be in such a database?
I cannot say because I have no idea what you mean by 'table' in this context.
How are they related?
If you mean mailboxes, they form a hierarchy, or a tree, so the relationship is parent-child and, by extrapolation, grandparent-grandchild and so on.
Pete
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the beauties of Eudora has been the fact that my MBox files can be
searched by a grep like tool, and that they are basically text. This
transparency I view as essential.
Now, if someone wants to build an indexing database on top of the plain
text storage, that would be a nice extension. But I view plain text storage
as one of the key benefits of Eudora (although would like attachments MIMEd
into the message itself).
Thanks to Eudora's statistics, I can tell you that at this moment I have
1,201,289 messages in my Eudora. And I feel sure that there will be plenty
more users with over a million, perhaps some with several million.
I still think priority numero uno should be at least an SQL database "under
the hood". I call upon Mr MacLean to help me with this.
This is a bit embarrassing for me as a person who has worked with
computers for nearly 50 years, who has taught Computer Science, and has
considerable expertise in several areas (operating systems , embedded
software, Internet protocols, etc.), but databases are a mystery to me. I
have never actively avoided them but I have never worked with them and know
almost nothing about them. I could not even begin to assess how useful or
appropriate an SQL database would be in an email client. So, sorry, but I
think I will not be able to help with this.
I am very inclined to trust your assertion that we should put a database
under the hood but I would still like to hear a few concrete examples of
how this would benefit the product. And, even if it is made priority numero
uno, I still think strongly that it should be such a priority for and only
for a second edition.
I can do better. I can send you my complete app. It's not sane right now,
so don't expect a working app. But in the File menu you'll find a "send"
setting or similar which will will open the Simple MAPI app.. Lemme just
make sure the code actually compiles here..
It's big so goglle does something cloudy with it...hang on,,,
I can do better. I can send you my complete app. It's not sane right now,
so don't expect a working app. But in the File menu you'll find a "send"
setting or similar which will will open the Simple MAPI app.. Lemme just
make sure the code actually compiles here...
Hermes.rar https://drive.google.com/file/d/1uyg_gNmfL_Tmw9xdv9P5C6oZzDYBANaY/view?usp=drive_web
There. If you cant access it tell me. I'll find another way....
Regards.
On Sat, Feb 9, 2019 at 9:09 PM sbrothy@gmail.com wrote:
I can do better. I can send you my complete app. It's not sane right now,
so don't expect a working app. But in the File menu you'll find a "send"
setting or similar which will will open the Simple MAPI app.. Lemme just
make sure the code actually compiles here...
Hermes.rar
There. If you cant access it tell me. I'll find another way....
Regards.
On Sat, Feb 9, 2019 at 9:09 PM sbrothy@gmail.com wrote:
I can do better. I can send you my complete app. It's not sane right now,
so don't expect a working app. But in the File menu you'll find a "send"
setting or similar which will will open the Simple MAPI app.. Lemme just
make sure the code actually compiles here...
Hermes.rar
Ah, you mean MFCMAPI! It never occurred to me. But this is something I know well and use often. And, yes, in a sense it is like an Outlook clone.
MFCMAPI is a great boon to people like myself who work heavily with Outlook and Exchange. But it is an application, not a library. Although, being open-source, parts of it could be extracted into a library. And that could be valuable should we ever want to make our product a client to Exchange. But I see no current demand for that and view it as something for perhaps a version 3 if at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We can easily enlarge the already exiting icons programmatically, on the
fly,^ but, without custom larger icons they will probably end up as blurry
copies though. The important lesson here is that it's possible, and pretty
easy at that. it may require some extra artwork. As far as I remember icons
are build so the same image contains the different sizes. So if someone has
an artistic st real se should be set....
The good news is that the icons I remember seeing in Eudora was already
big. Making Them smaller should be a breeze. I'll have a look.....m
R.
--
Søren Bro Thygesen
OK......we'll give you feedback on this when we start using the program.
Is the first release going to include an auto import of Eudora's accounts & settings?
The first "release" will be an empty GUI shell. I complicated some things
for myself deciding to have a dedicated (dockable/floatable/closable)
window for the "to", "from", "subject". "Cc", "bcc" and attachments. This
way, you can write an email using the entire screen. Much like a text
editor really. But with an MDI app this makes for some hard and/or
difficult decisions. I still like the idea though. And I'm nearly there.
What I'm fighting with right now is exactly the various ways this window
must be updated based on an ID (GUID) in each document.
All the data will still reside in the document. Only the display will be
handled by this window.
But for instance, what will this window display if there are e-mail text
windows on-screen, none of which are active? Decisions like that....
Regards,
Søren
On Monday, February 4, 2019, Walt Stagner wstagner@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
An auto import..? I'll have to see how Eudora stores it's settings as it
is. Must be doable though.....
Regards
On Monday, February 4, 2019, Walt Stagner wstagner@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
http://unixwiz.net/tools/eudinfo.html
Here's a link to where settings are: http://unixwiz.net/tools/eudinfo.html
First impressions mean something.
I'd suggest getting the Hermes look to actually
resemble Eudora on first beta.
The more it resembles Eudora the more we (the audience) will embrace it and crave more!
Last edit: Walt Stagner 2019-02-05
Yes, that´s first gonna happen on second beta, I've made a point out of
keeping the two projects apart initially.
I can copy the menu, even the toolbar but it will just be a bunch of empty
functions. Better we add the menu options and toolbar options when they
actually do something.
Youre gonna see something that doesnt resemble Eudora on first glance but I
promise you (and with McLean's promise regarding IMAP, we´ll be there in
no time at all.)
Especially with the DLLs from _Eudora. They're still good. At least the one
we have code for. Well even without the code, /DUMPBIN and GetProcAdress
was invented for reasons,
Regards.
Søren
On Tue, Feb 5, 2019 at 3:33 PM Walt Stagner wstagner@users.sourceforge.net
wrote:
I have a hard time understanding the "can only be set from the "ini-file
thingie". The options menu in Eudora looks pretty complete, But again
there will be no reaons to go around Hermers to make a change to a setting.
Why you've been puttinh up with this is really a little beyond me. How can
a program have options that are not configurable from within the program
itself? I'm seriously mystified.
R
On Wed, Feb 6, 2019 at 10:02 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I do not mean to say that I consider this is a good idea but the thinking might be that some rarely needed options should be settable only by manual intervention to keep less-sophisticated users from hurting themselves (and raising support costs!) by changing settings that generally should not be changed.
This is a very significant matter. I had supposed all along until now that what we produce would not have and not need any import capability but would simply work in place. There certainly are aspects of the way Eudora stores things that could be improved and, as our software evolves, should be improved. However I see no reason to change such things from the outset. It would mean developing an import utility that, as I see it, should not be necessary. Why do the extra work? That is both the extra work of designing and implementing a new storage system and the extra work of writing an importer. Eudora's system is awkward in certain ways but it is nevertheless efficient and scalable. My Eudora has 4,474 mailboxes holding around 1 million messages.
Mr Maclean, please note that Mr Thygesen is referring to settings import,
rather than mailbox import; we're doing a new GUI, so all it should do is
find the Eudora AppData directory and parse the eudora.ini file or
whatever. Your messages will stay in the format they are/
On Tue, 5 Feb 2019 at 11:59, Pete Maclean petemaclean@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!)
Ah, I read too much into Mr Thygesen's message. Sorry.
Jesus Kristus! I can see why you're loyal to the old client. And I agree
that an import script would be more or less a waste of time. Yes. There're
a lot of settings but not any more than it can be done manually. The new
client store the settings in binary where XML would perhaps have been a
better choice.
Regarding the look and feel of Eudora's GUI please don't despair at first
look. We will quickly make it recognizable. Remember also though , that
we're making a tigerleap MFC-version wise. As such you should expect the
new GUI to be just that: New.
Regards
Sørenmm
On Tuesday, February 5, 2019, Pete Maclean petemaclean@users.sourceforge.net wrote:
--
Søren Bro Thygesen
Many Eudora users are, I believe, accustomed to editing their Eudora.ini files to change settings. As far as I know, in the case of a few rare options, doing so is the only way to make changes. So the idea of storing them in binary makes me uneasy. Well, even the idea of changing how they are stored in the first place makes me wonder. However if there is a complete way of viewing and editing all settings in the GUI then it should be okay.
I've had bad luck trying to upload the "proof-of-concept" program I wrote
using Mercurial. I can pack it into a ZIP package and put it somewhere
complete with executable. I haven't really tried to make it look like
Eudora. I thought the better priority would be to make the things under the
hood work. Like actually sending a message. As I said I wrote myself into a
corner but I'm nearly in a sane place again.
As soon as we're more than one person on this we can make nice
splashscreens and toolbars. In my opnion though, as I think I've emphasised
numerous times, Making it send and receive a message is the hall - mark.
The stupid part is that, as you'll immediately see when you run the
application, a complete Microsoft Outlook clone is built into to the MFC
framework. So. Then. Why even do this?
I still think priority numero uno should be at least an SQL database "under
the hood". I call upon Mr MacLean to help me with this. I have a suspicion
he's the only one who understands what I mean when I'm talking about
"normalization" with respect to a database system design. We have a
Professor Emeritus from Northumbria University willing to help us with
this. Why the heck doesn't we go somewhere serious with the application?
And when I hear about the numnber of eamils involved. Millions?! WHAT THE
FUCK! (Pardon my French). But why didn't someone put a proper database
behind this monster before?
I dont' care about false news or spamming. I care about developing a
program that can do whatever people want. If that's what they want so be
it. Is just another front in another war I don't care about. I care about
the thing actually doing what we want. I basically want to play with LEGO.
Regards.
Søren
Regards,
Søren.
On Wednesday, February 6, 2019, Pete Maclean petemaclean@users.sourceforge.net wrote:
Thanks to Eudora's statistics, I can tell you that at this moment I have 1,201,289 messages in my Eudora. And I feel sure that there will be plenty more users with over a million, perhaps some with several million.
This is a bit embarrassing for me as a person who has worked with computers for nearly 50 years, who has taught Computer Science, and has considerable expertise in several areas (operating systems , embedded software, Internet protocols, etc.), but databases are a mystery to me. I have never actively avoided them but I have never worked with them and know almost nothing about them. I could not even begin to assess how useful or appropriate an SQL database would be in an email client. So, sorry, but I think I will not be able to help with this.
I am very inclined to trust your assertion that we should put a database under the hood but I would still like to hear a few concrete examples of how this would benefit the product. And, even if it is made priority numero uno, I still think strongly that it should be such a priority for and only for a second edition.
The numbers alone should make it obvious. But it depends upon the the
design ofcourse. I need to know what you mean by "mailboxes". How many
tables should be in such a database? How are they related? I can see
"CONTACTS" and "MESSAGES" as tables immediately. With attributes like sent
or not. Subjects, threading and all. I'´m surprised you've come as long as
you have without relating to a "Relational" database. :)
The data should be in a relational database management system. The view?
Well, how do you want to look at it?
Regards,
Søren
On Sat, Feb 9, 2019 at 8:52 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
Eudora uses the term "mailbox" in a sense that it is not standard. In Eudora, a 'mailbox' is a named container for messages. In Outlook the same thing is called a 'folder' and, I think it is fair to say in general, this is what most people would call a 'folder'.
I cannot say because I have no idea what you mean by 'table' in this context.
If you mean mailboxes, they form a hierarchy, or a tree, so the relationship is parent-child and, by extrapolation, grandparent-grandchild and so on.
Pete
One of the beauties of Eudora has been the fact that my MBox files can be
searched by a grep like tool, and that they are basically text. This
transparency I view as essential.
Now, if someone wants to build an indexing database on top of the plain
text storage, that would be a nice extension. But I view plain text storage
as one of the key benefits of Eudora (although would like attachments MIMEd
into the message itself).
Robert
On Sun, 10 Feb 2019 at 06:52 Pete Maclean petemaclean@users.sourceforge.net
wrote:
I am responding again, this time to another topic in your last message:
I am surprised but pleased to learn this. However I am also a little sceptical. Can you please point me to some relevant documentation?
I can do better. I can send you my complete app. It's not sane right now,
so don't expect a working app. But in the File menu you'll find a "send"
setting or similar which will will open the Simple MAPI app.. Lemme just
make sure the code actually compiles here..
It's big so goglle does something cloudy with it...hang on,,,
Regards..
On Sat, Feb 9, 2019 at 8:59 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
There. If you cant access it tell me. I'll find another way....
Regards.
On Sat, Feb 9, 2019 at 9:09 PM sbrothy@gmail.com wrote:
https://www.howto-outlook.com/downloads/mfcmapi.htm
As a beginning. But it's best you take your own look, I can't distinguish
this client from Outlook.
On Sat, Feb 9, 2019 at 9:12 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Yeah. "Windows Live Mail 2012", If it doesn't want to start just retry. it
will eventually.
Regards.
On Sat, Feb 9, 2019 at 9:16 PM sbrothy@gmail.com wrote:
Ah, you mean MFCMAPI! It never occurred to me. But this is something I know well and use often. And, yes, in a sense it is like an Outlook clone.
MFCMAPI is a great boon to people like myself who work heavily with Outlook and Exchange. But it is an application, not a library. Although, being open-source, parts of it could be extracted into a library. And that could be valuable should we ever want to make our product a client to Exchange. But I see no current demand for that and view it as something for perhaps a version 3 if at all.