I'm sure you can see what is wrong here. But according to the readme file
this file is autogenerated by "AppWizard"? Was this wizard drunk when
generating this?
10 errors can be removed by just moving the declaration of oemh out of the for loop, but is this the way to go, keeping in mind the file is
autogenerated?
I'm sure you can see what is wrong here. But according to the readme file
this file is autogenerated by "AppWizard"? Was this wizard drunk when
generating this?
10 errors can be removed by just moving the declaration of oemh out of the for loop, but is this the way to go, keeping in mind the file is
autogenerated?
Also Pete, take a look at my latest commit. I'm not sure if that is an
auto-generated section. You never mentioned using a WYSYWIG tool. I'll stop
here for now, and await your verdict.
The first one was an obvious syntax error. How errors like that creep in is
a little worrying.
I'm sure you can see what is wrong here. But according to the readme file
this file is autogenerated by "AppWizard"? Was this wizard drunk when
generating this?
10 errors can be removed by just moving the declaration of oemh out of the for loop, but is this the way to go, keeping in mind the file is
autogenerated?
Regards,
Soren
Pete. Please take a look here.... (scope problem in autogenerated file)
You mean the commit involving changes to PostMessage calls? There is something not quite right there. These calls are not to the Windows API function of that name but to an internal function. I suspect that the compilation errors you are trying to fix are arising because the compiler thinks they are calls to Windows' PostMessage which takes an HWND as a first argument. But actually they are calls to a function declared in "JWnd.h" which takes a UINT as its first argument. So, I suggest that the appropriate fix now is to remove the casts and find out why the compiler is not finding that JWnd header file. I would also be tempted to change the name of that function to avoid further confusion of this kind.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You mean the commit involving changes to PostMessage calls? There is
something not quite right there. These calls are not to the Windows API
function of that name but to an internal function. I suspect that the
compilation errors you are trying to fix are arising because the compiler
thinks they are calls to Windows' PostMessage which takes an HWND as a
first argument. But actually they are calls to a function declared in
"JWnd.h" which takes a UINT as its first argument. So, I suggest that the
appropriate fix now is to remove the casts and find out why the compiler is
not finding that JWnd header file. I would also be tempted to change the
name of that function to avoid further confusion of this kind.
And yes. I was almost (but not entirely as you can understand) sure that it
was standard Windows API functions. Especially as they had W endings in
their #defines/function synonyms. That's very Windows-ish.
You mean the commit involving changes to PostMessage calls? There is
something not quite right there. These calls are not to the Windows API
function of that name but to an internal function. I suspect that the
compilation errors you are trying to fix are arising because the compiler
thinks they are calls to Windows' PostMessage which takes an HWND as a
first argument. But actually they are calls to a function declared in
"JWnd.h" which takes a UINT as its first argument. So, I suggest that the
appropriate fix now is to remove the casts and find out why the compiler is
not finding that JWnd header file. I would also be tempted to change the
name of that function to avoid further confusion of this kind.
Pete. Please take a look here.... (scope problem in autogenerated file)
But, as not to stress too much, I may wait till tomorrow to undo it. Unless
you have a reason it should be done right away. It'll be the first thing I
do tomorrow. Guests have crept into my apartment. They need entertainment
and code rollbacks aren't high on their list of laughs. :)
And yes. I was almost (but not entirely as you can understand) sure that it
was standard Windows API functions. Especially as they had W endings in
their #defines/function synonyms. That's very Windows-ish.
Regards.
On Sat, Sep 22, 2018 at 8:41 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Good. Exactly why I wanted your eyes on this. I was in doubt about it. I'll
revisit this change. Thank you.
Regards.
On Sat, Sep 22, 2018 at 8:25 PM Pete Maclean
petemaclean@users.sourceforge.net %0Dpetemaclean@users.sourceforge.net
wrote:
You mean the commit involving changes to PostMessage calls? There is
something not quite right there. These calls are not to the Windows API
function of that name but to an internal function. I suspect that the
compilation errors you are trying to fix are arising because the compiler
thinks they are calls to Windows' PostMessage which takes an HWND as a
first argument. But actually they are calls to a function declared in
"JWnd.h" which takes a UINT as its first argument. So, I suggest that the
appropriate fix now is to remove the casts and find out why the compiler is
not finding that JWnd header file. I would also be tempted to change the
name of that function to avoid further confusion of this kind.
Pete. Please take a look here.... (scope problem in autogenerated file)
Thanks. I'm showing them the door now, but I'm not technically capable
anymore. Sorry to say. Some of them brought various forms of intoxicating
stuff. One of which is still hanging in the air (It's a nightmare to get
out of your curtains. :))
You'd think I was too old for that stuff, and I am. Unfortunately my
"friends" aren't all at my age.
Thanks. I'm showing them the door now, but I'm not technically capable
anymore. Sorry to say. Some of them brought various forms of intoxicating
stuff. One of which is still hanging in the air (It's a nightmare to get
out of your curtains. :))
You'd think I was too old for that stuff, and I am. Unfortunately my
"friends" aren't all at my age.
--
----- 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!)
You mean the commit involving changes to PostMessage calls? There is
something not quite right there. These calls are not to the Windows API
function of that name but to an internal >> function. I suspect that the
compilation errors you are trying to fix are arising because the compiler
thinks they are calls to Windows' PostMessage which takes an HWND as a first
argument. But actually they are calls to a function declared in "JWnd.h"
which takes a UINT as its first argument. So, I suggest that the
appropriate fix now is to remove the casts and
find out why the compiler is not finding that JWnd header file. I would
also be tempted to change the name of that function to avoid further
confusion of this kind.
Yes. A function rename may be necessry. Good news is that the files
JWnd.h/JWnd.cpp are there.
Bad news is that, even if I include the JWnd header, there's still name
clashes and explicitly casting to UINT doesn't work either. It'll then
complain that the proper cast is HWND.
You mean the commit involving changes to PostMessage calls? There is
something not quite right there. These calls are not to the Windows API
function of that name but to an internal function. I suspect that the
compilation errors you are trying to fix are arising because the compiler
thinks they are calls to Windows' PostMessage which takes an HWND as a
first argument. But actually they are calls to a function declared in
"JWnd.h" which takes a UINT as its first argument. So, I suggest that the
appropriate fix now is to remove the casts and find out why the compiler is
not finding that JWnd header file. I would also be tempted to change the
name of that function to avoid further confusion of this kind.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header
and source (which are in to different locations). We keep the one copy
right. We don't copy the files into indvidual projects. That would be a
mess. Not that it's pretty as it is, but we certainly don't want to keep
track of several versions of the same file, no.
Oh, I can do it, I'm sure. But what do we do with the JWnd header
and source (which are in to different locations). We keep the one copy
right. We don't copy the files into indvidual projects. That would be a
mess. Not that it's pretty as it is, but we certainly don't want to keep
track of several versions of the same file, no.
What hWnd? This makes no sense? The declaration doesn't fit the
variables used.
Regards.
On Mon, Sep 24, 2018 at 6:36 PM sbrothy@gmail.com wrote:
Nah, it's just a common resource directory. As far as I can tell.
On Mon, Sep 24, 2018 at 6:35 PM sbrothy@gmail.com wrote:
Wait...EuMemMgr isn't contained in the solution at all, or am I just
blind? Is this by design?
On Mon, Sep 24, 2018 at 6:32 PM sbrothy@gmail.com wrote:
But as soon as I change the name in the JWnd files the uses will pop
up as errors. Then it's just a matter of finding them in the bunch of
errors.'
On Mon, Sep 24, 2018 at 6:29 PM sbrothy@gmail.com wrote:
This pair of files should be lifted back in the hierachy as they're
used by several projects obviously.
Regards
On Mon, Sep 24, 2018 at 6:28 PM sbrothy@gmail.com wrote:
Oh, I can do it, I'm sure. But what do we do with the JWnd header
and source (which are in to different locations). We keep the one copy
right. We don't copy the files into indvidual projects. That would be a
mess. Not that it's pretty as it is, but we certainly don't want to keep
track of several versions of the same file, no.
In [...]Eudora71/Importers/OEImport/OEImportClass.cpp (~ line 2223-2225):
[...]
for( int oemh = 0; oemh < oeHeader.cbEntries; oemh++)
{
fread((char)&(oeInfoList[oemh].oeInfo), sizeof(OEMessageHeaderInfo),
1, m_fpiOEFile);
// Read the table
fseek(m_fpiOEFile, -1, SEEK_CUR);
oeInfoList[oemh].oeInfo.lValue &= 0x00FFFFFF;
}
oemh = 0;*
[...]
I'm sure you can see what is wrong here. But according to the readme file
this file is autogenerated by "AppWizard"? Was this wizard drunk when
generating this?
10 errors can be removed by just moving the declaration of oemh out of the
for loop, but is this the way to go, keeping in mind the file is
autogenerated?
Regards,
Soren
Why gmail removed a line shift and inserted an asterix I don't know. But
look close,
Regards
On Sat, Sep 22, 2018 at 6:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Also Pete, take a look at my latest commit. I'm not sure if that is an
auto-generated section. You never mentioned using a WYSYWIG tool. I'll stop
here for now, and await your verdict.
The first one was an obvious syntax error. How errors like that creep in is
a little worrying.
Regards.
On Sat, Sep 22, 2018 at 6:58 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
You mean the commit involving changes to PostMessage calls? There is something not quite right there. These calls are not to the Windows API function of that name but to an internal function. I suspect that the compilation errors you are trying to fix are arising because the compiler thinks they are calls to Windows' PostMessage which takes an HWND as a first argument. But actually they are calls to a function declared in "JWnd.h" which takes a UINT as its first argument. So, I suggest that the appropriate fix now is to remove the casts and find out why the compiler is not finding that JWnd header file. I would also be tempted to change the name of that function to avoid further confusion of this kind.
Good. Exactly why I wanted your eyes on this. I was in doubt about it. I'll
revisit this change. Thank you.
Regards.
On Sat, Sep 22, 2018 at 8:25 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
And yes. I was almost (but not entirely as you can understand) sure that it
was standard Windows API functions. Especially as they had W endings in
their #defines/function synonyms. That's very Windows-ish.
Regards.
On Sat, Sep 22, 2018 at 8:41 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
But, as not to stress too much, I may wait till tomorrow to undo it. Unless
you have a reason it should be done right away. It'll be the first thing I
do tomorrow. Guests have crept into my apartment. They need entertainment
and code rollbacks aren't high on their list of laughs. :)
Regards.
On Sat, Sep 22, 2018 at 8:53 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
No hurry. Do it tomorrow.
Thanks. I'm showing them the door now, but I'm not technically capable
anymore. Sorry to say. Some of them brought various forms of intoxicating
stuff. One of which is still hanging in the air (It's a nightmare to get
out of your curtains. :))
You'd think I was too old for that stuff, and I am. Unfortunately my
"friends" aren't all at my age.
Regards.
On Sat, Sep 22, 2018 at 9:34 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
And this is why I prefer coffee, Contalgin, and Bolivian marching powder.
Doesn't make the curtains stink and doesn't intoxicate. :)
On Sat, 22 Sep 2018 at 20:52, 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!)
Yes. A function rename may be necessry. Good news is that the files
JWnd.h/JWnd.cpp are there.
Bad news is that, even if I include the JWnd header, there's still name
clashes and explicitly casting to UINT doesn't work either. It'll then
complain that the proper cast is HWND.
What do we do about that? Pete?
Regards.
On Sat, Sep 22, 2018 at 8:25 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
I think the only sure recourse is to rename the function. Perhaps to "JWndPostMessage".
Yeah. I thought you'd say something like that. Should I try to do that?
It's not the only place JWnd is used I gather...
Regards.
On Mon, Sep 24, 2018 at 6:14 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
Yes, go ahead. Unless you would prefer that I do it -- I am totally willing. If you do it, please do be careful to try to find all occurrences.
Oh, I can do it, I'm sure. But what do we do with the JWnd header and
source (which are in to different locations). We keep the one copy right.
We don't copy the files into indvidual projects. That would be a mess. Not
that it's pretty as it is, but we certainly don't want to keep track of
several versions of the same file, no.
Regards.
On Mon, Sep 24, 2018 at 6:24 PM Pete Maclean petemaclean@users.sourceforge.net wrote:
This pair of files should be lifted back in the hierachy as they're used by
several projects obviously.
Regards
On Mon, Sep 24, 2018 at 6:28 PM sbrothy@gmail.com wrote:
But as soon as I change the name in the JWnd files the uses will pop up as
errors. Then it's just a matter of finding them in the bunch of errors.'
On Mon, Sep 24, 2018 at 6:29 PM sbrothy@gmail.com wrote:
Wait...EuMemMgr isn't contained in the solution at all, or am I just blind?
Is this by design?
On Mon, Sep 24, 2018 at 6:32 PM sbrothy@gmail.com wrote:
Nah, it's just a common resource directory. As far as I can tell.
On Mon, Sep 24, 2018 at 6:35 PM sbrothy@gmail.com wrote:
There's already a SendMessage function.They're both inline. And they do
both call the relevant Windows API version:
JWnd.h:
[code]
[...]
LRESULT SendMessage ( UINT uMsg ,
WPARAM wParam = 0 ,
LPARAM lParam = 0 )
{
ASSERT ( ::IsWindow ( m_hWnd ) ) ;
return ( ::SendMessage ( m_hWnd , uMsg , wParam , lParam ) ) ;
}
[...]
{/code]
ASSERT ( ::IsWindow ( m_hWnd ) ) ;
What hWnd? This makes no sense? The declaration doesn't fit the variables
used.
Regards.
On Mon, Sep 24, 2018 at 6:36 PM sbrothy@gmail.com wrote:
Related
Code: code
Oh Duh! Sorry member variable m_hWnd. Never mind.
Regards
On Mon, Sep 24, 2018 at 6:41 PM sbrothy@gmail.com wrote:
Related
Code: code
So really, this change calls for both SendMessage and PostMessage to be
renamed, right?
On Mon, Sep 24, 2018 at 6:42 PM sbrothy@gmail.com wrote:
Related
Code: code
And excuse my French but what the heck is the purpose of putting void in
a C++ constructor? Nothing?
It sure looks weird.
On Mon, Sep 24, 2018 at 6:44 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Related
Code: code
Putting a 'void' in a constructor does not hurt but I don't do it. Maybe some people just don't like empty parentheses.
Yeah, problem is it actually means something different in plain C if I
remember correctly..
On Monday, September 24, 2018, Pete Maclean petemaclean@users.sourceforge.net wrote:
--
Søren Bro Thygesen