C / C++ / MFC

Scanline problem in bitmap

10-Jan-08 2:37

sharanu wrote:
pAttNode->attributes->setNamedItem(pattIdAttr);

The above line is wrong, since pAttNode is NULL.

I changed that line with

pRootNode->attributes->setNamedItem(pattIdAttr);

and the file was correctly created (with the attribute added to the root element).
Smile | :)

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]

trioum10-Jan-08 0:39

trioum

10-Jan-08 0:39

i am using freeimage and see the code
fipImage m_image;
BYTE *byte= m_image.getScanLine(somevlaue);

Now do not want to use the freeimage can any one help me
(please not use MFC)that I have a bitmap file and get
the same byte pointer of Scanline of bitmap image

Trioum

CPallini10-Jan-08 2:42

10-Jan-08 2:42

Check out the GetDIBits function http://msdn2.microsoft.com/en-us/library/ms532334.aspx[^]

Smile | :)

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]

Mark Salsbery10-Jan-08 7:13

10-Jan-08 7:13

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++
Java | [Coffee]

trioum10-Jan-08 17:58

trioum

10-Jan-08 17:58

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

Mark Salsbery11-Jan-08 12:58

11-Jan-08 12:58

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)
{
   // Get information about the loaded DIBSection

   DIBSECTION DibSection;
   ::GetObject(hBitmap, sizeof(DibSection), &DibSection);


   // Calculate a pointer to the pixel data for a given scanline

   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);


   // Clean up

   ::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++
Java | [Coffee]

[Message Deleted]

trioum11-Jan-08 18:42

trioum

11-Jan-08 18:42

[Message Deleted]

Mark Salsbery12-Jan-08 7:32

Using handle between two process

12-Jan-08 7:32

Sure - I'll send an email.

You may want to remove your email from your post to avoid
extra spam Smile | :)

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

LockWindowUpdate & Vista

baerten9-Jan-08 23:54

baerten

9-Jan-08 23:54

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 Sigh | :sigh:

Does anyone knows this effect? Maybe also the correct technique to work around the problem?

Big thanks in advance Smile | :)

ashtwin9-Jan-08 23:29

ashtwin

9-Jan-08 23:29

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

Maxwell Chen9-Jan-08 23:37

9-Jan-08 23:37

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

CPallini9-Jan-08 23:47

9-Jan-08 23:47

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.
Smile | :)

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 Chen10-Jan-08 0:19

10-Jan-08 0:19

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. Smile | :)

CPallini wrote:
BTW handles technically are not memory addresses.

The type void* is memory address.

typedef void* HANDLE;

Maxwell Chen

CPallini10-Jan-08 0:36

10-Jan-08 0:36

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 Wink | ;)

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 Chen10-Jan-08 3:48

10-Jan-08 3:48

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). Smile | :)

// Process A.
struct MyBlock
{
  int a;
};
void main()
{
  MyBlock* p = new MyBlock; // p = 0x00A30210
  p->a = 3;
  // No delete to let it being kept.
}
// Process B.
struct MyBlock
{
  int a;
};
void main()
{
  void* p = reinterpret_cast<void*>(0x00A30210);
  cout << reinterpret_cast<myblock*>(p)->a;
}

Maxwell Chen

CPallini10-Jan-08 3:58

10-Jan-08 3:58

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]

Maxwell Chen10-Jan-08 4:08

10-Jan-08 4:08

I mean why it is not defined as below? Confused | :confused:

typedef  ULONG  HANDLE;

Maxwell Chen

CPallini10-Jan-08 4:35

Re: Using handle between two process [modified]

10-Jan-08 4:35

I don't know, but I can guess that 64-bit version of Windows use 64-bit HANDLEs.

Smile | :)

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]

CPallini10-Jan-08 4:18

10-Jan-08 4:18

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]

Smile | :)

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 Chen10-Jan-08 4:36

10-Jan-08 4:36

Maxwell Chen

Mark Salsbery10-Jan-08 7:19