|
code to make an Mdiform transparent
tony-yeyo
|
|
|
|
|
Handle the WM_ERASEBKGND Notification[^] and do nothing in the handler code
except return a non-zero value.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hey,
is there any way to wrap text in a CListCtrl Header? I know I can subclass and do some CustomDraw, but with this method I loose the XP style.
Thanks for your help!
|
|
|
|
|
BYTE *pBuf=GetBinaryOfOneJpegFileFromDatabase();
Need to construct a GdiPlus::Image object using the data pointed to by pBuf.
I found a way, but not so efficient
_variant_t varBLOB;
SafeArrayAccessData(varBLOB.parray,(void**)&pBuf);
SafeArrayUnaccessData (varBLOB.parray);
COleStreamFile stmFile;
stmFile.CreateMemoryStream();
stmFile.WriteHuge(pBuf,lDataSize);
IStream *pS=stmFile.GetStream();
m_pImg=::new Image(pS);
The data pointed to by pBuf is copied several times,
so is there an more efficient way?
Thanks.
|
|
|
|
|
followait wrote: is there an more efficient way?
What about using GlobalAlloc() and CreateStreamOnHGlobal() to
create a stream to pass to the Image ctor?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It must be better,
but there is a problem when call GlobalUnlock
IStream *pStm=NULL;
::CreateStreamOnHGlobal(NULL,TRUE,&pStm);
ULARGE_INTEGER ui;
ui.LowPart=lDataSize+1;
ui.HighPart=0;
HRESULT hr=pStm->SetSize(ui);
HGLOBAL hGlobal=NULL;
::GetHGlobalFromStream(pStm,&hGlobal);
BYTE *pBuf=(BYTE*)::GlobalLock(hGlobal);
::SafeArrayAccessData(varBLOB.parray,(void**)&pBuf);
::SafeArrayUnaccessData (varBLOB.parray);
BOOL b=::GlobalUnlock(hGlobal);
DWORD dw=::GetLastError();
modified on Monday, February 04, 2008 3:35:03 AM
|
|
|
|
|
|
I assume you found this already...
GlobalUnlock():
"If the memory object is still locked after decrementing the lock count,
the return value is a nonzero value. If the memory object is unlocked
after decrementing the lock count, the function returns zero and GetLastError
returns NO_ERROR.
If the function fails, the return value is zero and GetLastError returns a value other than NO_ERROR."
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I would agree with Mr. Salsbery.
IStream* pStream=NULL;
then use
CreateStreamOnHGlobal(NULL,TRUE,&pStream);
then use the streams "Write" method to get the data from the buffer in,
pStream->Write(pBuf,nSize,NULL);
then use Image::FromStream or the constructor as you had been doing.
|
|
|
|
|
Don't forget to initialize COM for this technique.
|
|
|
|
|
Hi everyone!
Would like to ask...
if i have a DLL that implements a function.. this DLL is used by an EXE. can the call to the DLL function by the EXE be done in parallel? say the EXE implements several thread and each of these threads calls the DLL function. or is the call just 1 at a time?
Thanks for any help.
not so newbie
|
|
|
|
|
The short answer is yes. Any number of threads can call a function in a DLL at the same time; the DLL calling mechanism allows this.
The real answer is it depends on the function in the DLL. The DLL function must be designed to be thread-safe. In other words, you must know that the function can be called from multiple threads safely. If the function uses a global resource, it must protect accesses to that resource so that its state isn't changed incorrectly by multiple threads.
If you don't know that the function is thread-safe, you can make it so by writing your own wrapper, something like this:
static CCriticalSection MyFunction_CS;
void Function(...);
void MyFunction(...)
{
MyFunction_CS.Lock();
Function(...);
MyFunction_CS.Unlock();
}Intead of calling Function(...) directly, you call MyFunction(...) which uses a critical section to ensure only a single thread at a time can call Function(...).
|
|
|
|
|
Hi! thanks so much for the answer.
if the function does not use global resoure and is something like below
void Function(myobj *obj){
myobj* objTemp = new myobj;
objTemp->a = obj->a;
};
will there be a problem if the function is called by multiple threads?
thanks again!
not so newbie
|
|
|
|
|
This depends on the myobj class, and the type of member 'a'. If 'a' is a simple type (an int for example) then this code is probably thread-safe as it is. If it is something more complicated that has its own assignment operator, then this function might not be safe.
Suppose a is a linked list of items allocated from a global pool. The assignment operator that performs the objTemp->a = obj->a operation would probably need to allocate items from the global pool. That might make this operation and this function not thread-safe.
|
|
|
|
|
sorry but what do you mean by global pool?
thanks.
not so newbie
|
|
|
|
|
A common approach to keeping the size of a data structure limited is to allocate a fixed number of items and place them in a list of their own at the beginning of the program. This list is called the 'pool'. When the program needs a new item, it removes one from the pool. When it's done with the item, it puts it back in the pool. If the pool is ever empty when it needs a new item, it knows that the data structure has reached its size limit and it can react accordingly.
This pool is a global resource. If you were to have multiple threads accessing it, thread 1 could be partway through removing an entry from the pool while thread 2 could attempt to add an entry to the pool. Pointers to the beginning and end of the pool could be set incorrectly. Later accesses might try to get an item from the pool that is really in use elsewhere, or items might be lost instead of being returned to the pool.
|
|
|
|
|
im not sure if i understand what you meant by a the global resource...
however the struct myobj as shown before is created everytime the function is called and sent as a data to a named pipe then the function returns.
will there be a problem in that case?
|
|
|
|
|
A 'global resource' is an object in the program that will be accessed by more than one thread.
|
|
|
|
|
does named pipe count? if the function is writing to the named pipe and the function is called in parallel will that be a problem? or does named pipe handle that scenario automatically?
if not then i should only call the write function to the named pipe one at a time.
|
|
|
|
|
A named pipe certainly counts. I wouldn't think that named pipe access would be thread-safe. Proper thread safety depends on too many external factors. If you are using overlapped I/O, that changes things as well.
The conservative approach would be to protect your write function with a critical section.
|
|
|
|
|
You can call the DLL function in parallel, of course. But you have to be careful since your DLL function maybe not thread safe.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
hi thanks for the answer....
now my problem is if i dont use a lock within the function... and the function is as shown below
void function(myobj* obj)
{
myobj *objTemp = new myobj;
objTemp->a = obj->a; // or if i use memcpy here
send to namepipe...
}
will there be a problem if the function is called in parallel?
thanks again.
|
|
|
|
|
You have to worry about shared resources, inside your function, as far shared resources are not used you're safe. You should try to figure out what happens if the thread executing the function loses the CPU possibly in favour of another thread running the same function: if such action is harmless, then you're safe (for instance if the named pipe is shared then a meaningless message can result if the threads write in parallel to)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
then my question next question will be if the named pipe is used only by that function.. however if that function is called in parallel causing 2 or more writing in the named pipe will that be a problem? or is it automatically handled by the named pipe that if there is currently a write in progress then other write functions will not interfere until it is finished?
|
|
|
|
|
CPalline wrote: or instance if the named pipe is shared then a meaningless message can result if the threads write in parallel to
CPallini already answered that question for you. If you can write to the named pipe at the same time from multiple threads, then it doesn't matter if it would be the same function or different functions - It's still BAD.
After all, the talking-to-the-named-pipe won't happen in MyFunctionA, or MyFunctionB - it will happen in ::WriteFile, which both of your functions can call.
Iain.
Iain Clarke appearing by Special Request of CPallini.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
