|
[edited - I shouldn't watch FIFA World Cup and answer questions at the same time]
You should use Release when you're done with interface returned from QueryInterface call.
Have no idea about GetObject.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
QI calls AddRef() on your behalf internally, calling it again on the returned pointer means you now have 2 references on the interface pointer and need to call Release() twice...
See: ATLBase.h 5374 (your line numbers may vary  ) for an example QI implementation:
ATLINLINE ATLAPI AtlInternalQueryInterface(
void* pThis,
const _ATL_INTMAP_ENTRY* pEntries,
REFIID iid,
void** ppvObject)
{
ATLASSERT(pThis != NULL);
ATLASSERT(pEntries->pFunc == _ATL_SIMPLEMAPENTRY);
if (ppvObject == NULL)
return E_POINTER;
*ppvObject = NULL;
if (InlineIsEqualUnknown(iid))
{
IUnknown* pUnk = (IUnknown*)((int)pThis+pEntries->dw);
pUnk->AddRef();
*ppvObject = pUnk;
return S_OK;
}
...
Len Holgate
www.jetbyte.com
The right code, right now.
|
|
|
|
|
This happens when you watch a game and surf CP. Anyway, Senegal leads 1 after first half
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
|
Braulio Díez wrote:
Should I Release this pointer or not ?
LPDISPATCH pDisp = Fmt.GetObject();
Yes. A function has returned you an interface, it will have called AddRef() before it returned it to you, you now own a reference to the interface and should call Release() when you're done with it.
Braulio Díez wrote:
And in this case ?
BSREPORTCTRLSLib::IBsMetafile *pIBsMeta;
pDisp->QueryInterface(IID_IBsMetafile, (void **) &pIBsMeta);
Again, yes. You've called QI, that results in the interface that is returned to you being AddRef()'d, you now own a reference to the interface and should call Release().
In both cases you have bare interface pointers so you're responsible for managing the reference counts. Generally, if you have bare pointers and a function returns you an interface you need to call Release() when you're done.
Len Holgate
www.jetbyte.com
The right code, right now.
|
|
|
|
|
Every reference to an interface needs to be released...
Mauricio Ritter - Brazil
Sonorking now: 100.13560 Trank
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) The alcohol is one of the greatest enemys of man, but a man who flee from his enemys is a coward.
|
|
|
|
|
when I click in my editbox,I want all the contents to be
selected,I used these code:
void CCaculatorDlg::OnSetfocusEDITap1()
{
CEdit* ped=(CEdit*)GetDlgItem(IDC_EDIT_ap1);
ped->SetSel(0, -1, FALSE);
}
but it doesnt work, when I click at the editbox, it
just like havent added these code.
what could I do?
|
|
|
|
|
Did you try handling GetFocus instead of SetFocus?
modified 12-Sep-18 21:01pm.
|
|
|
|
|
but there's no message like GetFocus,
(I look it up in class wizard)
|
|
|
|
|
Use EN_SETSEL
-----
// editHWnd is the handle to your edit control
// from and to are the beginning and end of your select range
SendMessage(editHWnd, EM_SETSEL, static_cast<wparam>(from),
static_cast<lparam>(to));
-----
Kuphryn
|
|
|
|
|
There's no EN_SETSEL.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
I meant EM_SETSEL.
Kuphryn
|
|
|
|
|
And what do you think CEdit::SetSel does?
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
There are more than one way to get it working. Using EM_SETSEL is another method. I recommend trying that method to see if get the design where you want it.
Kuphryn
|
|
|
|
|
Just FYI, CEdit::SetSel is a thin wrapper which sends EM_SETSEL. So there's no difference, unless you want to achieve macho-API posture. 
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
Two things: First (as I go into Pedantic mode...)
Anonymous wrote:
CEdit* ped=(CEdit*)GetDlgItem(IDC_EDIT_ap1);<br />
ped->SetSel(0, -1, FALSE);
I would recommend that you do not get into the habit of casting the return value of GetDlgItem(...) to a CEdit* (or other class type) like that. There are certain situations where GetDlgItem(...) will return a pointer to a real CEdit (or other Control Class) object, but if you do not know what those situations are, it is best to avoid this entirely. Bind a CEdit member variable to the control, and use it instead.
True, in the case of MFC, doing that is usually safe, but in general C++ practices, it is a bad thing to do: you do not know if the pointer returned by GetDlgItem(...) is, or ever was, a pointer to an actual CEdit object.
Second, try using PostMessage(...) to send yourself the EM_SETSEL message from inside the OnSetFocus handler.
BTW: CWnd::OnSetFocus(...) is a standard function. What is OnSetfocusEDITap1 supposed to be? You may be handling the WM_SETFOCUS message incorrectly.
Peace!
-=- James.
"Some People Know How To Drive, Others Just Know How To Operate A Car."
(Try Check Favorites Sometime!)
|
|
|
|
|
yeah, I thought there must be sth wrong with the function
OnSetfocusEDITap1,I thought may be there is a function
named OnGetFocus...., but I failed to find it.
Have you met this question?
|
|
|
|
|
Hi
I have a CDialog based app which queries a data to gainthe information it requires to fill up the controls, but it takes a bit of time atm and i've not got it threaded or anything...which do people reckon is better...write a thread handler to get the info and a timer to check if the thread is finished...or use a callback function?
Bryce
I reckon callback fwiw
|
|
|
|
|
bryce wrote:
write a thread handler to get the info and a timer to check if the thread is finished
Just before returning from thread function use PostMessage to notify your dialog that processing is done.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
bryce wrote:
I reckon callback fwiw
You would still need something to do the work of gathering the data and calling the callback function.
Depending on how long it takes, I would consider using a thread, as has already been suggested. For example, if it took 30 seconds to gather the information, I might use a worker thread so that the UI would remain responsive and I could give the user the chance to cancel if they got tired of waiting.
But if it would only take 5-10 seconds, I would just let the user sit there looking at a Wait Cursor (after drawing the dialog at least once, of course). Also, even though threads are considered the "correct" way to do things, sometimes a little message-pump in between steps works well enough that users will not notice the difference.
YMMV.
Peace!
-=- James.
"Some People Know How To Drive, Others Just Know How To Operate A Car."
(Try Check Favorites Sometime!)
|
|
|
|
|
Neither, until you figure out why the data retrieval is taking so long. If you optimize the query, you won't need to wait for the data.
|
|
|
|
|
OK...I have looked at many different articles about threads, all say the same thing, but when i do it, it says this:-
'AfxBeginThread' : none of the 2 overloads can convert parameter 1 from type 'void (void)'
so i wondered if there is an include that i need or something?
==================================================
Homepage: www.onyeyiri.co.uk
Email: theeclypse@hotmail.com
"I'm not any old Eclypse, i'm TheEclypse..get it, got it, good!"
|
|
|
|
|
AfxBeginThead is in AfxWin.h, which should already be included in an MFC app-wizard generated application.
Post the code and somebody might be able to spot your error.
Michael
Errata 1: p. 154, section 'Defusing'. For 'red wire' read 'blue wire'.
|
|
|
|
|
void CSpeakItDlg::OnSpeakit()
{
AfxBeginThread(DoSpeak, this);
}
void CSpeakItDlg::DoSpeak()
{
ISpVoice * pVoice = NULL;
if (FAILED(CoInitialize(NULL)))
{
AfxMessageBox("Error to intiliaze COM");
return;
}
HRESULT hr = CoCreateInstance(CLSID_SpVoice, NULL, CLSCTX_ALL, IID_ISpVoice, (void **)&pVoice);
if( SUCCEEDED( hr ) )
{
hr = pVoice->Speak(m_sText.AllocSysString(), 0, NULL);
pVoice->Release();
pVoice = NULL;
}
CoUninitialize();
}
UINT CSpeakItDlg::DoSpeak(LPVOID lpv)
{
CSpeakItDlg * me = (CSpeakItDlg *)lpv;
me->DoSpeak();
return 0;
}
==================================================
Homepage: www.onyeyiri.co.uk
Email: theeclypse@hotmail.com
"I'm not any old Eclypse, i'm TheEclypse..get it, got it, good!"
|
|
|
|
|
Is your DoSpeak thread function declared as static in the header?
Michael
Errata 1: p. 154, section 'Defusing'. For 'red wire' read 'blue wire'.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
