I was to busy showing off with a smartpointer in the code
(std::unique_ptr), trying to work around the JWnd::SendMessage and
JWnd::PostMessage problem. They're not static, and the JWnd class
encapsulates a HWND member (it even overrides operator HWND(?)).
Since I don't know the memory penalty for creating them "on the stack", I
decided to create them on the heap. Hence the autoptr.
Even without smartpointers my scheme may work. What worries me is that the
code, again, is in an auto generated section!
I think we need to have a discussion about this problem. This is the only
place I can find a reference to JWnd. I'm pretty sure we may be better
of(f) without it.
tl;dr:
I don't like JWnd. It seems needlessly complicated and it's only used in
that one file (workbook.h). I'd like it out.
If OT501 is indeed the only static library then that's the best news I've
heard so far. Isn't OT501 basically the user interface and the ineffable
despicability we reluctanty refer to as Stingray?
I was to busy showing off with a smartpointer in the code
(std::unique_ptr), trying to work around the JWnd::SendMessage and
JWnd::PostMessage problem. They're not static, and the JWnd class
encapsulates a HWND member (it even overrides operator HWND(?)).
Since I don't know the memory penalty for creating them "on the stack", I
decided to create them on the heap. Hence the autoptr.
Even without smartpointers my scheme may work. What worries me is that the
code, again, is in an auto generated section!
I think we need to have a discussion about this problem. This is the only
place I can find a reference to JWnd. I'm pretty sure we may be better
of(f) without it.
tl;dr:
I don't like JWnd. It seems needlessly complicated and it's only used in
that one file (workbook.h). I'd like it out.
If OT501 is indeed the only static library then that's the best news I've
heard so far. Isn't OT501 basically the user interface and the ineffable
despicability we reluctanty refer to as Stingray?
Regards
On Wednesday, October 3, 2018, Pete Maclean petemaclean@users.sourceforge.
net wrote:
That may indeed be the answer. I have suspected since early on that this
is the case.
As far as I've understood, you're mainly doing your development on Windows
right? In your opinion, which DLL do you think would make the best
candidate for porting to POSIX? I mean, which one is the stablest, and have
the least Windows-specific code?
I'm thinking of doing an experiment. Linux might have open source libraries
for most of what we want to do, but to fit into the original QUALCOMM
code (I'm never gonna let myself forget that stoned-out question!), we're
going to have to conform.
This makes my idea of using WxWidgets even more appealing to me.
News flash: they put a man on the moon!
Just kidding, but seriously, I thought we'd moved
long past debating this and onto implementing it.
Especially as Strongay
Are you high again? Or is this a joke? Sorry, sometimes I can't tell.
uses names similar to MFC's. This makes the
problem of separating them intractable bordering on downright impossible.
Not really. Stingray classes are
"SECMDIChildWnd", "SECWorksheet", "SECFrodo",
while MFC classes are along the lines of
"CGandalf" (without the SE). MSHTML classes are
"CTridentView", "CTridentPreviewView",
"CTridentReadMessageView" and "CTridentBilbo".
No. Not impossible but unnecessarily complicated
True.
Regards
On Wednesday, October 3, 2018, sbrothy@gmail.comsbrothy@gmail.com wrote:
(AFK)
Then, ipso facto, all we really need is a new user interface...
Along with making all the DLLs work and
portable, and handle characters. And a ton of
stuff I probably haven't thought of.
Piece of cake. :P
Regards
On Wednesday, October 3, 2018, Pete Maclean
<mailto:petemaclean@users.sourceforge
.net>petemaclean@users.sourceforge .net wrote:
That was a joke. I'm not "stoned" on any regular basis. That was a one time
occurence. I didn't know what I was thinking that day. You could tell by
how stoned that one toke actually made me. :)
It was just an epiphany for me that all the projects were DLLs. This hadn't
really dawned upon me and will make our/my live(s) much easier. Take the
spell checker for instance, I was under the impression I would have to
insert an interface between a static lib and the rest of the program. If
it's a DLL it'll be much easier. Working copies of the DLLs will be a big
help though, so I can analyse what precisely they export. I did find
exported functions already though, working DLL or not.
About WxWidgets I have had problems making it work. On both Linux and
Windows. It's just a wall that needs to be punched through though. It will
take off like a rocket all of a sudden.
This makes my idea of using WxWidgets even more appealing to me.
News flash: they put a man on the moon!
Just kidding, but seriously, I thought we'd moved
long past debating this and onto implementing it.
Especially as Strongay
Are you high again? Or is this a joke? Sorry, sometimes I can't tell.
uses names similar to MFC's. This makes the
problem of separating them intractable bordering on downright impossible.
Not really. Stingray classes are
"SECMDIChildWnd", "SECWorksheet", "SECFrodo",
while MFC classes are along the lines of
"CGandalf" (without the SE). MSHTML classes are
"CTridentView", "CTridentPreviewView",
"CTridentReadMessageView" and "CTridentBilbo".
No. Not impossible but unnecessarily complicated
True.
Regards
On Wednesday, October 3, 2018,
sbrothy@gmail.comsbrothy@gmail.com wrote:
(AFK)
Then, ipso facto, all we really need is a new user interface...
Along with making all the DLLs work and
portable, and handle characters. And a ton of
stuff I probably haven't thought of.
I'm not happy with the fact that it's static,
but this implies that the rest are DLLs and, for the most part, work, no?\
Vous avez raison. Most of Eudora (and now
HERMES) is linked dynamically. While some of the
DLL's don't compile (per Maclean), fixing them so
they do is apparently not a hard job.
Now you're gonna puncture my "happy-balloon" somehow. I just know it.
Unfortunately, there are a few DLL's that we'll
have to unlink and use something
else. MSHTML.dll is the big one (Trident, for
viewing messages). Another one is ssce5232.DLL,
which is the Wintertree spell checker. Unless of
course we make the decision to buy the source
from Wintertree, but given that it costs $5000,
I'm a bit reluctant to do that; I'd prefer to
replace it with Nuspell or Hunspell.
I was to busy showing off with a smartpointer in
the code (std::unique_ptr), trying to work
around the JWnd::SendMessage and
JWnd::PostMessage problem. They're not static,
and the JWnd class encapsulates a HWND member
(it even overrides operator HWND(?)).
Since I don't know the memory penalty for
creating them "on the stack", I decided to
create them on the heap. Hence the autoptr.
Even without smartpointers my scheme may work.
What worries me is that the code, again, is in an auto generated section!
I think we need to have a discussion about this
problem. This is the only place I can find a
reference to JWnd. I'm pretty sure we may be better of(f) without it.
tl;dr:
I don't like JWnd. It seems needlessly
complicated and it's only used in that one file (workbook.h). I'd like it out.
If OT501 is indeed the only static library then
that's the best news I've heard so far. Isn't
OT501 basically the user interface and the
ineffable despicability we reluctanty refer to as Stingray?
Regards
On Wednesday, October 3, 2018, Pete Maclean
petemaclean@users.sourceforge. net wrote:
That may indeed be the answer. I have suspected
since early on that this is the case.
If OT501 is indeed the only static library then that's the best news
I've heard so far. Isn't OT501 basically the user interface and the
ineffable despicability we reluctanty refer to as Stingray?
OT501 stands for Objective Toolkit 5.01. So, yes. That is what we
loosely refer to as Stingray. More specifically, Stingray is the
name of the company that first wrote OT (in other words, before they
turned into a bunch of a-holes). Saying "Stingray" to mean Objective
Toolkit is kind of like saying "Google" to mean the Chrome web
browser, or saying "Microsoft" to mean Windows.
As for the history of that company, Stingray Inc. was bought out by
Rogue Wave, then Rogue Wave was bought out by Quovadx. When Quovadx
was bought out by a bunch of investment bankers, they decided to spin
off Rogue Wave into a separate company again.
Regards
On Wednesday, October 3, 2018, Pete Maclean <mailto: petemaclean@users.sourceforge.net="">petemaclean@users.sourceforge.net wrote:</mailto:>
That may indeed be the answer. I have suspected since early on that
this is the case.
I didn't check.
I was to busy showing off with a smartpointer in the code
(std::unique_ptr), trying to work around the JWnd::SendMessage and
JWnd::PostMessage problem. They're not static, and the JWnd class
encapsulates a HWND member (it even overrides operator HWND(?)).
Intuitively, something looks needlessly complicated here.
Since I don't know the memory penalty for creating them "on the stack", I
decided to create them on the heap. Hence the autoptr.
Even without smartpointers my scheme may work. What worries me is that the
code, again, is in an auto generated section!
I think we need to have a discussion about this problem. This is the only
place I can find a reference to JWnd. I'm pretty sure we may be better
of(f) without it.
tl;dr:
I don't like JWnd. It seems needlessly complicated and it's only used in
that one file (workbook.h). I'd like it out.
If OT501 is indeed the only static library then that's the best news I've
heard so far. Isn't OT501 basically the user interface and the ineffable
despicability we reluctanty refer to as Stingray?
Regards
On Wednesday, October 3, 2018, Pete Maclean petemaclean@users.sourceforge.net wrote:
--
Søren Bro Thygesen
(AFK)
To clear up:
I'm not happy with the fact that it's static, but this implies that the
rest are DLLs and, for the most part, work, no?
Now you're gonna puncture my "happy-balloon" somehow. I just know it.
Regards
On Wednesday, October 3, 2018, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
Søren Bro Thygesen
I think you have it right. No puncturing needed.
(AFK)
Then, ipso facto, all we really need is a new user interface...
Along with making all the DLLs work and portable, and handle characters.
And a ton of stuff I probably haven't thought of.
Piece of cake. :P
Regards
On Wednesday, October 3, 2018, Pete Maclean petemaclean@users. sourceforge.net wrote:
--
Søren Bro Thygesen
(AFK)
This makes my idea of using WxWidgets even more appealing to me.
Especially as Strongay uses names similar to MFC's. This makes the problem
of separating them intractable bordering on downright impossible.
No. Not impossible but unnecessarily complicated
Regards
On Wednesday, October 3, 2018, sbrothy@gmail.com wrote:
--
Søren Bro Thygesen
As far as I've understood, you're mainly doing your development on Windows
right? In your opinion, which DLL do you think would make the best
candidate for porting to POSIX? I mean, which one is the stablest, and have
the least Windows-specific code?
I'm thinking of doing an experiment. Linux might have open source libraries
for most of what we want to do, but to fit into the original QUALCOMM
code (I'm never gonna let myself forget that stoned-out question!), we're
going to have to conform.
Regards.
On Wed, Oct 3, 2018 at 5:07 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
At 04:07 PM 10/3/2018, you wrote:
News flash: they put a man on the moon!
Just kidding, but seriously, I thought we'd moved
long past debating this and onto implementing it.
Are you high again? Or is this a joke? Sorry, sometimes I can't tell.
Not really. Stingray classes are
"SECMDIChildWnd", "SECWorksheet", "SECFrodo",
while MFC classes are along the lines of
"CGandalf" (without the SE). MSHTML classes are
"CTridentView", "CTridentPreviewView",
"CTridentReadMessageView" and "CTridentBilbo".
True.
That was a joke. I'm not "stoned" on any regular basis. That was a one time
occurence. I didn't know what I was thinking that day. You could tell by
how stoned that one toke actually made me. :)
It was just an epiphany for me that all the projects were DLLs. This hadn't
really dawned upon me and will make our/my live(s) much easier. Take the
spell checker for instance, I was under the impression I would have to
insert an interface between a static lib and the rest of the program. If
it's a DLL it'll be much easier. Working copies of the DLLs will be a big
help though, so I can analyse what precisely they export. I did find
exported functions already though, working DLL or not.
About WxWidgets I have had problems making it work. On both Linux and
Windows. It's just a wall that needs to be punched through though. It will
take off like a rocket all of a sudden.
Regards.
On Thu, Oct 4, 2018 at 2:04 AM Ted Matavka nmatavka@users.sourceforge.net
wrote:
At 03:52 PM 10/3/2018, you wrote:
That's what i've been saying time and again. The
only thing really preventing this from compiling is the UI.
You don't need to think of that stuff. That's
the Lord High Everything Else's job.
As Lord High Everything Else, I have spent
unhealthy amounts of time planning out exactly what needs to be done:
QCSSL is not yet done and I am still working on it. It has at least one deficiency which is that it will not connect to Zimbra.
At 02:52 PM 10/3/2018, you wrote:
Vous avez raison. Most of Eudora (and now
HERMES) is linked dynamically. While some of the
DLL's don't compile (per Maclean), fixing them so
they do is apparently not a hard job.
Unfortunately, there are a few DLL's that we'll
have to unlink and use something
else. MSHTML.dll is the big one (Trident, for
viewing messages). Another one is ssce5232.DLL,
which is the Wintertree spell checker. Unless of
course we make the decision to buy the source
from Wintertree, but given that it costs $5000,
I'm a bit reluctant to do that; I'd prefer to
replace it with Nuspell or Hunspell.
At 02:30 PM 10/3/2018, you wrote:
OT501 stands for Objective Toolkit 5.01. So, yes. That is what we
loosely refer to as Stingray. More specifically, Stingray is the
name of the company that first wrote OT (in other words, before they
turned into a bunch of a-holes). Saying "Stingray" to mean Objective
Toolkit is kind of like saying "Google" to mean the Chrome web
browser, or saying "Microsoft" to mean Windows.
As for the history of that company, Stingray Inc. was bought out by
Rogue Wave, then Rogue Wave was bought out by Quovadx. When Quovadx
was bought out by a bunch of investment bankers, they decided to spin
off Rogue Wave into a separate company again.