|
Where are you trying to use your hLogPal?
You should be using a HGLOBAL instead of a HANDLE for program clarity, but that is a side point.
Are you locking your hLogPal pointer with GlobalAlloc before you try to use it? because the GHND flag specifies that your memory should be moveable, and it requires to be locked before you can access the actual memory.
Unless you plan on shareing this memory with another process, or you are do some COM work, it may be easier to manage your memory with new and delete.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
My hLogPal is being used inside a CreateDIBPalette() function (which i think came originally from MSDN). The lines I quoted are fairly near the start of the function, and these lines are the first point at which I do anything with hLogPal.
This function gets called at part of the New Document routine, just after the DIB data has been allocated memory. I only try and lock a pointer to the hLogPal after this step, but it doesn't get that far - the access violation occurs on this line.
how would I manage this using new and delete rather than GlobalAlloc() (not having had a great deal of experience using GlobalAlloc() in the past i am unsure of the exact mechanics)? It sounds like this would be the best idea (I am not doing any COM or multi-process work). As I am at work at the mo I will fiddle with it when I get home.
Thanks a lot Paul - i'll have another look and get back to you.
-Alex
|
|
|
|
|
Nope. no joy.
main problem seems to stem from the fact that i'm using DIB's (really, really irritating). To create a new palette I need to create a new CPalette (which i'm doing) and then attach an array of PALETTEENTRY's, after first attaching them to a LOGPALETTE. Problem is - i need to allocate these with GlobalAlloc() (new just won't compile).
Do you think that this is a symptom of an invalid pointer somewhere else. Same app - Get access violation at the same address when I try to display a CFileDialog.
Cheers, Alex.
|
|
|
|
|
Hi!
I develop WIN32 software that uses MySQL database. My software uses MySQL
ODBC driver 3.51 and ADO interface. MDAC 2.7 is installed. My problem is
that while I'm trying to update MySQL record contained char(15) field, I get
an error "Microsoft OLE DB Provider for ODBC Drivers Multiple-step OLE DB
operation generated errors. Check each OLE DB status value, if available. No
work was done." I don't have such problem with numeric fields. The numeric
fields are updating normally with the same code.
Here is a sample of my code:
try
{
_RecordsetPtr pRecordset;
HRESULT hr;
_bstr_t btmp;
hr = pRecordset->Open(vTable, vConnection,adOpenForwardOnly,
adLockOptimistic, adCmdTableDirect);
hr = pRecordset->AddNew();
...
pRecordset->Fields->GetItem(L"id")->Value=btmp;
...
pRecordset->Fields->GetItem(L"proto")->Value=btmp;
...
pRecordset->Fields->GetItem(L"src_ip")->Value=btmp;
}
The fields "id" and "proto" are numeric, the field "src_ip" is char. And I
get the above error while updating the "src_ip" field. Do you have any
ideas? Can you help me?
Yours sincerely,
Alex Bash
|
|
|
|
|
You should check individual error values to find out why it fails. OLE DB throws an array of errors using IErrorRecord interface. You should check them:
if( m_adoConnection->Errors->Count > 0 )
{
for( long iError = 0; iError < m_adoConnection->Errors->Count; ++iError )
{
ErrorPtr adoError = m_adoConnection->Errors->Item[iError];
// Do something with the error
}
}
Vagif Abilov
MCP (Visual C++)
Oslo, Norway
Hex is for sissies. Real men use binary. And the most hardcore types use only zeros - uppercase zeros and lowercase zeros.
Tomasz Sowinski
|
|
|
|
|
If I have a worker thread (let's call it thread B) and I have a control on my main window whose WndProc() is in the main application thread (thread A), and I use SendMessage() to the control from thread B, is the message processed in thread A or in thread B? What about with PostMessage()?
Jeff Sand
jsand at interaccess dot com
|
|
|
|
|
The message is processed in A in both cases.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Are you sure about that? When you SendMessage you call the WndProc directly, bypassing the pump. So SendMessage would be in the context of the worker thread, while PostMessage would be in the context of the main thread (which runs the message pump). This is also the way COM handles a call to a STA component (by posting messages instead of calling the components interfaces directly).
Of course, I may be wrong 
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Are you sure about that?
I'm 100% sure, if you pardon my arrogance. SendMessage only bypasses the message pump if issued from the same thread that attends the message. Otherwise, the message is queued as usual and the caller thread blocks until the target thread processes the message.
As a side note, using SendMessage from worker threads is likely, if no care is taken, to result in deadlocks.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Relaying facts is not arrogance! I should have read the MSDN entry on SendMessage more carefully:
If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message.
No doubt here. I stand corrected  . But at least I was right on the "I could be wrong"-part 
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Well, as happens so often, 100% sureness is a hard position to maintain
As for the thread context switch, there's still no doubt about it. What I'm not so sure is whether the message sent gets queued or not. My hunch, after re-reading the docs, is that it is not, so it surpasses all other messages currently queued in the target thread. Most of the time this is of little relevance, I guess.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
I'm not so sure is whether the message sent gets queued or not
It doesn't (checked and 100% sure ).
rechi
|
|
|
|
|
Thanx for the info! How did you do the test (just curious)?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I've created a SDI application with a menu item used to start the worker.
The code:
void CMainFrame::OnFileThread()
{
DWORD *th=new DWORD;
HANDLE h=::CreateThread(NULL, 0, ThreadProc_, m_hWnd,
0, th);
Sleep(3000);
delete th;
}
DWORD WINAPI ThreadProc_(
LPVOID lpParameter
)
{
MSG msg;
TRACE("in thread proc\n");
::PostMessage((HWND)lpParameter, WM_DUMMY3, 0, 0);
::SendMessage((HWND)lpParameter, WM_DUMMY2, 0, 0);
return 0;
}
LRESULT CMainFrame::Func2(WPARAM, LPARAM)
{
MSG msg;
TRACE("in dummy2\n");
while (::GetMessage(&msg, NULL, 0, 0))
if (msg.message==WM_DUMMY3)
{
TRACE("found dummy3\n");
return 0;
}
return 0;
}
And the debug output:
in thread proc
in dummy 2
found dummy 3
Due to your obvious programming skills, it should be enough .
rechi
|
|
|
|
|
Hmmm. The docs suggest that the message goes through the queue ("Messages sent between threads are processed only when the receiving thread executes message retrieval code."), but doesn't specify if it gets in front of the line or has to wait until the messages in front is processed. Where's Jeff Richter or Mike Blaszczak when you need them  ? Anyway, it's probably of little consequence.
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
|
In A as the others have said. It is not a good idea to use SendMessage between threads as you are asking for a deadlock to come knocking on your door.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Why does it flicker sooo much inside a CMainFrame()...?
Do I have to set the CMainFrame() to WS_CLIPCHILDREN..? Should I make sure the CMainFrame() returns false inside OnEraseBkgnd()...?
How can I get rid of the flicker...?
Thank u muchly
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Does anybody know some easy way to handle and
create jpeg pictures? Some free library,
or something
Regards
Janne
|
|
|
|
|
VS7
google.
How low can you go ?
(enculage MS)
|
|
|
|
|
ROTFL !!!!
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
You mean like CXImage, FreeImage or GDI+ ? All three are documented here on CP.
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
|
I have the following code:
In CMainFrame::OnCreate() function:
...
m_pCbRooms = (CComboBox*) CComboBox::FromHandle(::GetDlgItem(hBar, ID_ROOMS_COMBO));
...
I also have the following function in the CMainFrame class:
void CMainFrame::UpdateRoomList(const CMeasureData* pMeasureData, int nCurrentRoom)
{
ASSERT_VALID(pMeasureData);
ASSERT(nCurrentRoom >= 0 && nCurrentRoom < pMeasureData->GetRoomCount());
ASSERT(m_pCbRooms != NULL);
m_pCbRooms->SetRedraw(FALSE);
m_pCbRooms->ResetContent();
for (int n = 0; n < pMeasureData->GetRoomCount(); n++)
{
const CRoom* proom = pMeasureData->GetRoom(n);
ASSERT(proom != NULL);
m_pCbRooms->AddString(proom->GetDescription());
}
m_pCbRooms->SetCurSel(nCurrentRoom);
m_pCbRooms->SetRedraw(TRUE);
m_pCbRooms->Invalidate();
m_pCbRooms->UpdateWindow();
}
When I call this function in the constructor of my CDocument class it works fine, but when I call this function in some CLICK-Event function, there is a ASSERTION in "afxwin2.inl" in line 120.
In the CLmsPPCDoc::OnNewRoom() event (ASSERTION):
...
((CMainFrame*) AfxGetMainWnd())->UpdateRoomList(m_pMeasureData, 0);
...
What's wrong?
Daniel
---------------------------
Never change a running system!
|
|
|
|
|
The ASSERT seems to imply that m_pCbRooms does not point to a created window when CMainFrame::UpdateRoomList is called.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
