|
As you have explained above, you mean you have included the head file "omnithread.h" correctly.
May be you haven't defined the preprocess macro such as "__SINIX__", "__osr5__", "__irix__", so error "No implementation header file" occurs.
Tommorrow is another day.
|
|
|
|
|
Thanks for reply.
As you told that preprocesser macro may not be defined i tried to see its defination but it shows it is not defined.But the same other project is running by doing the same thing and it doesn,t give error to it.But I am doing the same thing and it gives me the error.
The diff is only that I include header file like #include "omnithread\omnithread.h" and in other project it is like #include<omnithread.h>.
If any other suggetion then reply.I will appreciate your answer.
Thanks.
Ashish Bhatt
|
|
|
|
|
I want to do a program with 3 views, in 2 of them graphic (these views are derived from CVIEW) and on the other side I want to put a file explorer (similar to Windows Explorer). But not the kind that resulted in CTreeView or CTreeCtrl. Besides not initialize where the component and declare.
Thanks.
|
|
|
|
|
Do you want to make your tree control of course with graphics functions for files?
|
|
|
|
|
Point foobar()
{
Point local;
Point *heap = new Point;
*heap = local;
// ... stuff ...
delete heap;
return local;
}
There is a question on the source above.
Since point heap points to the object 'local', there is no need to new the point 'local'
If I change 'Point * heap = new Point' to 'Point * heap', Isn't the source more effective?
Another question is that if the class Point hasn't define the destructor function, We know
that the compiler will define the default destructor function itself.
But if I delete heap, will the call of default destructor be called?
Many thanks.
Tomorrow is another day.
|
|
|
|
|
richardye wrote: Since point heap points to the object 'local', there is no need to new the point 'local'
heap does not point to local.
richardye wrote: *heap = local;
This is a copy by value
richardye wrote: If I change 'Point * heap = new Point' to 'Point * heap', Isn't the source more effective?
No, the copy by value above will fail
richardye wrote: But if I delete heap, will the call of default destructor be called?
yep
|
|
|
|
|
|
richardye wrote: If I change 'Point * heap = new Point' to 'Point * heap', Isn't the source more effective?
Yes but in this case there should be a small change in the code. You should assign
the address of local to heap.
Point foobar()
{
Point local;
Point *heap = new Point;
*heap = local;
Point *heap = &local;
// ... stuff ...
delete heap;
return local;
}
richardye wrote: But if I delete heap, will the call of default destructor be called?
Yes. But if you are modifying the code as i meantioned above you should not call delete.
|
|
|
|
|
Naveen.R wrote: Point *heap = &local;
Provided he is not changing the value in the *heap.
- NS -
|
|
|
|
|
richardye wrote: Since point heap points to the object 'local'...
It would if you had done:
Point *heap = &local; richardye wrote: ...there is no need to new the point 'local'
And if you tried to, the compiler would complain because local is not a pointer.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi,
I want to extract images from a CImageList and save them as transparent GIF files. I'm using the following GDI+ code and the transparent area comes out black.
<code>
const HICON hIcon = myImageList.ExtractIcon( nImage );
Bitmap* gdiBMP = Bitmap::FromHICON( hIcon );
CLSID encoderClsid;
GetEncoderClsid( T2W( "image/gif" ), &encoderClsid );
Status stat = gdiBMP->Save( L"myfilename.gif", &encoderClsid, NULL );
delete gdiBMP;
</code>
Have Google'd and searched CP to no avail. Any/all suggestions most welcome.
|
|
|
|
|
Does something like this work?
IMAGEINFO imageinfo;
myImageList.GetImageInfo(nImage, &imageinfo);
int width = imageinfo.rcImage.right - imageinfo.rcImage.left;
int height = imageinfo.rcImage.bottom - imageinfo.rcImage.top;
Bitmap TransparentBitmap(width, height, PixelFormat32bppARGB);
Graphics *pBitmapGraphics = Graphics::FromImage(&TransparentBitmap);
pBitmapGraphics->SetCompositingMode(CompositingModeSourceCopy);
SolidBrush TransparentBrush(Gdiplus::Color::Transparent);
pBitmapGraphics->FillRectangle(&TransparentBrush, 0, 0, width, height);
HDC hdc = pBitmapGraphics->GetHDC();
ImageList_Draw(myImageList, nImage, hdc, 0, 0, ILD_TRANSPARENT);
pBitmapGraphics->ReleaseHDC(hdc);
delete pBitmapGraphics;
CLSID encoderClsid;
GetEncoderClsid( T2W( "image/gif" ), &encoderClsid );
Status stat = TransparentBitmap.Save( L"myfilename.gif", &encoderClsid, NULL ); Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi Mark,
Thanks for the reply. I've got a feeling your code isn't the answer, but I'll give it a try.
|
|
|
|
|
Good luck 
There's a little trial and error involved in figuring out which combination of
GDI and GDI+ calls preserve alpha and transparency data.
It may look ridiculously complicated for a seemingly simple operation, but with GDI
especially, alpha and transparency data is pretty much ignored except with DIBSections.
Please let me know what works for you!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
BTW, try just drawing the icon anywhere on a window or the screen
right after the ExtractIcon call. Does it still have transparency?
If not - that's where you're losing the "background".
If so, then you're losing transparency when crossing the GDI-GDI+
line when you call FromHICON().
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: BTW, try just drawing the icon anywhere on a window or the screen
right after the ExtractIcon call. Does it still have transparency?
Good question. I suspect it doesn't have transparency at this point. Comments in articles on CP refer to "black" pixels where the transparent pixels should be.
I think I need to convert the C# code at http://www.bobpowell.net/giftransparency.htm[^] into C++, but I'm not a C# guy.
I've started converting them by hand as quick stop-gap measure.
|
|
|
|
|
Neville Franks wrote: I suspect it doesn't have transparency at this point
Well, I tested it. Both of our versions of code keep the transparency fine.
Of course, yours was much simpler
The GDI+ Save code, however, ignores it. Same with PNG.
Find a solution yet (beyond that link)?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
I'm going to take a look at making a C++ version today.
The selection of the transparent color should be automatic.
FWIW, saving the icon as a TIFF preserves the transparency 
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote: I'm going to take a look at making a C++ version today.
Sounds great. Look forward to seeing how you go.
|
|
|
|
|
Hi Mark,
Did you ever get this written and working?
|
|
|
|
|
OMG I never even looked at it again!
Wow, that was really a year ago? Man, did I get sidetracked 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I'm doing binary file input and I want to read 4 32-bit values in binary from a file with the read() command as elegantly as possible. Read gives me back a pointer to a char array of 16 chars (16 bytes of binary data representing the 4 32-bit values, called headerValPtr)
So I have a simple struct:
myStruct
{
int
int
float
float
}
My data types in the struct are 32-bit unsigned integers and floating point vals. So I create a pointer to myStruct and allocate memory for it, call it sillyStruct. Will it work to then say sillyStruct = (myStruct*)headerValPtr? I just want to typecast the binary data into the 4 values in the struct.
I don't have a good textbook handy to see how struct allocates memory. If the struct pointer simply points to a set of consecutive memory locations that hold all of the data, then I'm good. But I'm not 100% sure that is the case.
If you want real code snippets I can throw something together, but this is more of a theoretical question so maybe you can live without?
Thanks,
--Seth
|
|
|
|
|
|
It's like trying to herd a pack of fish!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
