There's a seemingly unused member of CMFCPropertyGridProperty called dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would gobble
those right up (now we're speskingvof it)?
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h); [/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
There's a seemingly unused member of CMFCPropertyGridProperty called dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would gobble
those right up (now we're speskingvof it)?
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h); [/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
There's a seemingly unused member of CMFCPropertyGridProperty called
dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would
gobble
those right up (now we're speskingvof it)?
But I'm guessing a little here. I've read tons about function poiinters but
little seem to have stuck. :(
Regards.
On Thu, Jan 3, 2019 at 6:17 PM sbrothy@gmail.com wrote:
Setting it doesn't seem so big a a task:
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open
Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h); [/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
On Thu, Jan 3, 2019 at 4:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
There's a seemingly unused member of CMFCPropertyGridProperty called
dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would
gobble
those right up (now we're speskingvof it)?
I gave up on cramming it in to the dwData member because it may not bw able
to hold it. What it can hold, though, is a simple index to a map of
pointers to functions.
So that's my plan now: creating a look up map for the darn things .
But I'm guessing a little here. I've read tons about function poiinters but
little seem to have stuck. :(
Regards.
On Thu, Jan 3, 2019 at 6:17 PM sbrothy@gmail.com wrote:
Setting it doesn't seem so big a a task:
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open
Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h); [/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
On Thu, Jan 3, 2019 at 4:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
There's a seemingly unused member of CMFCPropertyGridProperty called
dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would
gobble
those right up (now we're speskingvof it)?
Oh man. 6+ hours tonight. I'm almost there. I'll stop for tonight
because further attempts will be detrimental to the overall effort. I'll
archive where I'm at because that turned out to be a life saver. I 'm down
to 5 errors and that's not too bad. Especially when all member variants are
OLE data and std::maps of functions poniter that can be serialized in one
go.
I don't remember the deadline (Mr. Matavka? I can present somethin now but
I'd rather show the full monty. Especially when I'm, so close.).....
I gave up on cramming it in to the dwData member because it may not bw able
to hold it. What it can hold, though, is a simple index to a map of
pointers to functions.
So that's my plan now: creating a look up map for the darn things .
The syntax is a bitch though.
I'll keep you posted....
R
On Friday, January 4, 2019, Soren Bro sbrothy@users.sourceforge.net wrote:
I got the solution. It's fireproof, waterproof, SCORPION STARE proof, and
generelle abc-conjecture proof.
I'll implement this tonight and then we'te rolling...
Regards
On Friday, January 4, 2019, Soren Bro sbrothy@users.sourceforge.net wrote:
I realise I'm probaly mostly sparring with myself here, but so be it...
Sorry, GetSet is typedef'd as:
typedef void (CHermesSettings::GetSet)(void );*
OUTSIDE the CHermesSettings classs.
I guess a similar result could be obtained by declaring
But I'm guessing a little here. I've read tons about function poiinters but
little seem to have stuck. :(
Regards.
On Thu, Jan 3, 2019 at 6:17 PM sbrothy@gmail.com wrote:
Setting it doesn't seem so big a a task:
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open
Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h); [/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
On Thu, Jan 3, 2019 at 4:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
There's a seemingly unused member of CMFCPropertyGridProperty called
dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would
gobble
those right up (now we're speskingvof it)?
The deadline is 1 February, but it's very much a private one. I recommend working as fast as possible, but no faster. Commit your code to Hg if you can, and present it when it's done.
Sent from my BlackBerry — the most secure mobile device
From: sbrothy@users.sourceforge.net
Sent: 5 January 2019 17:34
To: general@discussion.hermesmail.p.re.sourceforge.net
Reply to: general@discussion.hermesmail.p.re.sourceforge.net
Subject: [hermesmail:discussion] Re: settings
Oh man. 6+ hours tonight. I'm almost there. I'll stop for tonight
because further attempts will be detrimental to the overall effort. I'll
archive where I'm at because that turned out to be a life saver. I 'm down
to 5 errors and that's not too bad. Especially when all member variants are
OLE data and std::maps of functions poniter that can be serialized in one
go.
I don't remember the deadline (Mr. Matavka? I can present somethin now but
I'd rather show the full monty. Especially when I'm, so close.).....
I gave up on cramming it in to the dwData member because it may not bw able
to hold it. What it can hold, though, is a simple index to a map of
pointers to functions.
So that's my plan now: creating a look up map for the darn things .
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open
Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h);
[/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
There's a seemingly unused member of CMFCPropertyGridProperty called
dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would
gobble
those right up (now we're speskingvof it)?
There's a seemingly unused member of CMFCPropertyGridProperty called dwData
(SetData (...) / GetData (...)). This can be used to store a function
pointer back to the settings class. This will prevent what I feared: a
gigant switch construct based io strings - and i18n strings at that!
Also, The settings scream out to be variant_t s.
CMFCPoropertyGridProperty already uses these, and any database would gobble
those right up (now we're speskingvof it)?
Regards
--
Søren Bro Thygesen
Setting it doesn't seem so big a a task:
[CODE]
CMFCPropertyGridProperty *tmp = new CMFCPropertyGridProperty(_T("Auto open
Mail Detail"), (_variant_t)pSettings->m_bAutoOpenAddressInfo, _T("Open Mail
Detail on document open."));
GetSet gs = &CHermesSettings::SetAutoOpenMailDetail;
DWORD_PTR h = reinterpret_cast<dword_ptr>(&gs);
tmp->SetData(h);
[/CODE]</dword_ptr>
Retrieving it, on the other hand, seems to be more difficult;
[CODE
// Cast the lparam to a property.
CMFCPropertyGridProperty * pProperty = (CMFCPropertyGridProperty *)lParam;
ASSERT(pProperty);
DWORD_PTR dp = pProperty->GetData();
GetSet ds = (DWORD_PTR *)dp;
// GetSet gs = (GetSet)dp;
[/CODE]
Regards.
On Thu, Jan 3, 2019 at 4:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
I realise I'm probaly mostly sparring with myself here, but so be it...
Sorry, GetSet is typedef'd as:
typedef void (CHermesSettings::GetSet)(void );*
OUTSIDE the CHermesSettings classs.
I guess a similar result could be obtained by declaring
typedef void (GetSet)(void *); *
Inside the class.
I'm considering changing it to:
void (CHermesSettings::PFN_GETSETVARIANT)(_variant_t &)*
or
variant_t & (CHermesSettings::PFN_GETSETVARIANT)(_variant_t &)*
But I'm guessing a little here. I've read tons about function poiinters but
little seem to have stuck. :(
Regards.
On Thu, Jan 3, 2019 at 6:17 PM sbrothy@gmail.com wrote:
I got the solution. It's fireproof, waterproof, SCORPION STARE proof, and
generelle abc-conjecture proof.
I'll implement this tonight and then we'te rolling...
Regards
On Friday, January 4, 2019, Soren Bro sbrothy@users.sourceforge.net wrote:
--
Søren Bro Thygesen
Ok. Generic pointers to member functions...
Not funny.
I gave up on cramming it in to the dwData member because it may not bw able
to hold it. What it can hold, though, is a simple index to a map of
pointers to functions.
So that's my plan now: creating a look up map for the darn things .
The syntax is a bitch though.
I'll keep you posted....
R
On Friday, January 4, 2019, Soren Bro sbrothy@users.sourceforge.net wrote:
--
Søren Bro Thygesen
Oh man. 6+ hours tonight. I'm almost there. I'll stop for tonight
because further attempts will be detrimental to the overall effort. I'll
archive where I'm at because that turned out to be a life saver. I 'm down
to 5 errors and that's not too bad. Especially when all member variants are
OLE data and std::maps of functions poniter that can be serialized in one
go.
I don't remember the deadline (Mr. Matavka? I can present somethin now but
I'd rather show the full monty. Especially when I'm, so close.).....
Regards.
On Sat, Jan 5, 2019 at 1:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
Oh man. 6+ hours tonight. I'm almost there. I'll stop for tonight
because further attempts will be detrimental to the overall effort. I'll
archive where I'm at because that turned out to be a life saver. I 'm down
to 5 errors and that's not too bad. Especially when all member variants are
OLE data and std::maps of functions poniter that can be serialized in one
go.
I don't remember the deadline (Mr. Matavka? I can present somethin now but
I'd rather show the full monty. Especially when I'm, so close.).....
Regards.
On Sat, Jan 5, 2019 at 1:56 PM Soren Bro sbrothy@users.sourceforge.net
wrote:
settings
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/