|
|
I'd give you some sample code if you can provide more specifics.
Are the "bitmap" files always .BMP files or do you want to support
other file types?
Can you use ATL or only straight Win32 APIs?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
at present I am using only .bmp files then will use other file format
(i.e.jpeg ,png gif,tga etc).
I am using only plan sdk (win32 only).
Trioum
|
|
|
|
|
For BMP files, here's a simple method...
HBITMAP hBitmap = (HBITMAP)::LoadImage(NULL, _T("C:\\Some.bmp"), IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION | LR_LOADFROMFILE);
if (hBitmap)
{
DIBSECTION DibSection;
::GetObject(hBitmap, sizeof(DibSection), &DibSection);
LONG scanline = ...;
BYTE *pScanlineBytes;
if (DibSection.dsBmih.biHeight > 0)
pScanlineBytes = (BYTE*)DibSection.dsBm.bmBits + (DibSection.dsBm.bmWidthBytes * ((DibSection.dsBm.bmHeight - 1) - scanline));
else
pScanlineBytes = (BYTE*)DibSection.dsBm.bmBits + (DibSection.dsBm.bmWidthBytes * scanline);
::DeleteObject(hBitmap);
}
For other file formats, you need to either parse the file yourself and provide any
decompression necessary, or you can use a third-party library. For Win32 in C++
you can use GDI+ to load png, jpeg, tiff, gif, exif, and bmp. If you want to use
GDI like the code above once the image is loaded, then the GDI+ Bitmap::GetHBITMAP()
method will give you a DIBSection handle (HBITMAP) from a GDI+ Bitmap object.
If you can use C++, I would recommend using the ATL CImage class. It will handle all the
image types that GDI+ handles, and has simple methods for accessing scanlines as I've
demonstrated above.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
|
Sure - I'll send an email.
You may want to remove your email from your post to avoid
extra spam
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi everybody,
In MFC the new frames,views and controls appears in there own way.
So it seems ugly for the user if the new window opens under blitting...
I used the technique of LockWindowUpdate, which works great ... Under XP
Under Windows Vista this don't seem to work, the new frame opens in 2-4 steps
which seems very ugly
Does anyone knows this effect? Maybe also the correct technique to work around the problem?
Big thanks in advance
|
|
|
|
|
Hi, i am using FindWindow() function to get the handle of a dialog in one process from some other process. Can anybody tell is that correct or any problem in using the handle of a window in one process from some other process.
Thanks
|
|
|
|
|
A handle is actually a memory address. The handle (AKA: memory address) which you get from another process may be invalid to current process, because each process has its own view to memory (memory paging issue).
Maxwell Chen
|
|
|
|
|
I disagree. A window handle is unique on the system. You can post messages to the window whose that handle is assigned. At the end PostMessage is an IPC mechanism.
BTW handles technically are not memory addresses.
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]
|
|
|
|
|
CPallini wrote: I disagree. A window handle is unique on the system. You can post messages to the window whose that handle is assigned. At the end PostMessage is an IPC mechanism.
There is a translation mechanism.
CPallini wrote: BTW handles technically are not memory addresses.
The type void* is memory address.
typedef void* HANDLE;
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: There is a translation mechanism.
Maxwell Chen wrote: The type void* is memory address.
The type void* is a number that may contain a memory address. Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ).
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]
|
|
|
|
|
CPallini wrote: The type void* is a number that may contain a memory address.
I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void* ), it must be some address pointing to something.
CPallini wrote: Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ).
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap. Maybe it would be similar (not 100%) to this kind of thing below (I do not have VC++ now, not sure ).
struct MyBlock
{
int a;
};
void main()
{
MyBlock* p = new MyBlock;
p->a = 3;
}
struct MyBlock
{
int a;
};
void main()
{
void* p = reinterpret_cast<void*>(0x00A30210);
cout << reinterpret_cast<myblock*>(p)->a;
}
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. An window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying a window.
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]
|
|
|
|
|
I mean why it is not defined as below?
typedef ULONG HANDLE;
Maxwell Chen
|
|
|
|
|
I don't know, but I can guess that 64-bit version of Windows use 64-bit HANDLE s.
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]
|
|
|
|
|
Maxwell Chen wrote: I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. A window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying one particular window. Even supposing it is a memory address it cannot be a memory address in the context of any process in the user space, i.e. deferencing it in such processes is meaningless.
Maxwell Chen wrote: I guess that creating handle and free handle are something related with global allocating memory blocks in the heap
There's no hope to obtain shared memory the way you depicted. the reinterpret_cast has nothing to do with it (BTW it acts always in the context of the running process and it doesn't changes the pointer address). If you want shared memory you've to ask Windows a HANDLE , i.e. a number: the OS itself will never return to you a direct pointer to.
MSDN [^] states:
Memory objects allocated by GlobalAlloc and LocalAlloc are in private, committed pages with read/write access that cannot be accessed by other processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is not actually shared globally as it is in 16-bit Windows. This value has no effect and is available only for compatibility. Applications requiring shared memory for other purposes must use file-mapping objects. Multiple processes can map a view of the same file-mapping object to provide named shared memory. For more information, see File Mapping.
[added]
See also http://en.wikibooks.org/wiki/Windows_Programming/Handles_and_Data_Types[^]
[/added]
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]
modified on Thursday, January 10, 2008 10:29:24 AM
|
|
|
|
|
Maxwell Chen
|
|
|
|
|
That really is wrong.
Handles in Windows are opaque - they can be anything the system
implements them as. Whether they are pointers, indexes, integers, floats,
or anything else is irrelevant to the programmer.
All Windows handles are documented as to whether they are local to a
process or system-wide.
Window handles (HWND) are system-wide, so they are the same regardless of
the process using them.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You can use of EnumWindows instead FindWindow,do you want to send data to other window?
|
|
|
|
|
Hamid. wrote: You can use of EnumWindows instead FindWindow
Correct: EnumWindows is usually a better choice than FindWindow , but, Hamid, you're digressing...
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]
|
|
|
|
|
If ashtwin said what does he want to do was better than ask a general question.
|
|
|
|
|
Just kidding . Anyway his question is clear, he missed only the question mark:
ashtwin. wrote: Can anybody tell is that correct or any problem in using the handle of a window in one process from some other process.
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]
|
|
|
|
|
Yes you can use it. But when using it, take care about the operations. You cant use all APIs, or messages directly.
|
|
|
|
|
Hi,
thanks u all for replying. Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine.
Thanks
|
|
|
|