Re: Black Border around Dialog Box. - C / C++ / MFC Discussion Boards

gothic_coder9-Oct-08 0:59

9-Oct-08 0:59

Nah.. I'm not using these message handlers..

i'm using only.

WM_INITDIALOG
WM_CTLCOLORSTATIC
WM_ERASEBKGND

That's all...

Re: Black Border around Dialog Box.

Nishad S9-Oct-08 1:20

Nishad S

9-Oct-08 1:20

What is in WM_CTLCOLORSTATIC? Let's look into that too...

- NS -
[ODBaseBtn]

Re: Black Border around Dialog Box.

gothic_coder9-Oct-08 1:47

gothic_coder

9-Oct-08 1:47

WM_CTLCOLORSTATIC is where i make my static control transparent...

case WM_CTLCOLORSTATIC:
{
        if(hwndstatic == GetDlgItem(hWnd, IDC_STATIC_TEXT)
        {
	 HBRUSH hbr;
	 SetBkMode((HDC)wParam, TRANSPARENT);
	 hbr=(HBRUSH)GetStockObject(NULL_BRUSH);
	 return (LONG)hbr;
        }
}

Defined hwndstatic as lparam...

Re: Black Border around Dialog Box.

Nishad S9-Oct-08 2:54

Nishad S

9-Oct-08 2:54

This code seems as good... Frown | :(

If you can, please mail me full source... If I could reproduce the problem, there is some hope.

- NS -
[ODBaseBtn]

Re: Black Border around Dialog Box.

gothic_coder9-Oct-08 3:01

gothic_coder

9-Oct-08 3:01

Sure...Just gimme yur mail id...

Thanks.

Re: Black Border around Dialog Box.

Nishad S9-Oct-08 17:34

Nishad S

9-Oct-08 17:34

ns.nest@gmail.com

- NS -
[ODBaseBtn]

Re: Black Border around Dialog Box.

gothic_coder9-Oct-08 21:29

gothic_coder

9-Oct-08 21:29

Did You got the mail??

I send it...

Re: Black Border around Dialog Box.

Nishad S9-Oct-08 23:36

Nishad S

9-Oct-08 23:36

Yep... problem got... and solved... Smile | :)

You should not call DefWindowProc in the dialogproc. Instead you should return TRUE if you processed the message and FALSE if you did not.

int CALLBACK AnimateWindow(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
 switch(Msg)
 {
  case WM_INITDIALOG:
   ....
   ....
   break;

  default:
   return FALSE;
 }
 return TRUE;
}

Hope it will help you... Smile | :)

- NS -
[ODBaseBtn]

Re: Black Border around Dialog Box.

gothic_coder10-Oct-08 0:32

gothic_coder

10-Oct-08 0:32

Wooaahhhhh...
Sweet..Thanks a ton...

But when AnimateWindow don't work then the loop redirect to else part where i manually shift the window... say in Win95 and NT.. There it doesn't show black border while i return same what i was returning in case of AnimateWindow API.... What the reason behind that??

Re: Black Border around Dialog Box.

Nishad S10-Oct-08 1:13

Nishad S

10-Oct-08 1:13

I didn't dig it more... The possibility is that it might missing default painting...

From MSDN, the Remarks of AnimateWindow says "The window procedures for the window and its child windows should handle any WM_PRINT or WM_PRINTCLIENT messages. Dialog boxes, controls, and common controls already handle WM_PRINTCLIENT. The default window procedure already handles WM_PRINT"

Have a try to watch the messages processed when the AnimateWindow is called... Smile | :)

You can use Spy++ tool. Anyway I am not in a situation to spend that much time... Wink | ;)

- NS -
[ODBaseBtn]

different result on x86 and x64

George_George8-Oct-08 20:43

George_George

8-Oct-08 20:43

Hello everyone,

For the following code, on x86 build, the output is

000000C8
000000C8

and on x64 build, the output is

CCCCCCCC000000C8
00000000000000C8

I think the reason is, for x64, both void* and void** are 64bit, for for x86 void* and void** are 32 bit, and for int, always 32bit for both x86 and x64.

This line of code "void* b2 = *b1", dereference b1 and makes it into 64-bit on x64, which concatenate value of a 0x000000C8 and previous DWORD 0xcccccccc, so forms the result 0xCCCCCCCC000000C8.

But on x86, when dereference b1 and makes it into 32-bit on x86, and recovers to original value 0x000000C8.

In my understanding correct?

#include <iostream>

using namespace std;

int main()
{

	int a = 200;

	void** b1 = (void**)&a;

	void* b2 = *b1;

	int b3 = (int)*b1;

	cout << (void*)b2 << endl;

	cout << (void*)b3 << endl;

	return 0;
}

thanks in advance,
George

Re: different result on x86 and x64

CPallini9-Oct-08 0:27

CPallini

9-Oct-08 0:27

George_George wrote:
and previous DWORD 0xcccccccc

I think it is the next DWORD.
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.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Re: different result on x86 and x64

George_George9-Oct-08 0:58

George_George

9-Oct-08 0:58

Thanks CPallini,

So, you agree with my analysis in my original post? Smile | :)

regards,
George

Re: different result on x86 and x64

CPallini9-Oct-08 1:01

CPallini

9-Oct-08 1:01

Yes.

Re: different result on x86 and x64

George_George9-Oct-08 1:08

George_George

9-Oct-08 1:08

Thanks CPallini,

Question answered.

regards,
George

Re: different result on x86 and x64

gscotti9-Oct-08 4:47

gscotti

9-Oct-08 4:47

George,

I really think type casting should be avoided at all matters!!
If you stick with compiler native conversion, you would probably get a warning or even an error (like you did casting an int out of a void *).

int type is totally architecture dependent. That's why I'd stick with __int[8,16,32,64] or boost::int[8,16,32,64]

Re: different result on x86 and x64

George_George9-Oct-08 18:41

George_George

9-Oct-08 18:41

Could we use __int[8,16,32,64] in VC? I did some search but not find results.

regards,
George

Re: different result on x86 and x64

C^hris L^osinger9-Oct-08 9:17

C^hris L^osinger

9-Oct-08 9:17

just a note: the "DWORD" type is 32 bits in both Win32 and x64

image processing toolkits | batch image processing

Re: different result on x86 and x64

George_George9-Oct-08 18:42

George_George

9-Oct-08 18:42

I understand and agree. But does it relates to my original question? Smile | :)

regards,
George

Bluebox - Chromakey etc

Pixinger778-Oct-08 20:17

Pixinger77

8-Oct-08 20:17

Hello

I'm looking for a fast way to scan a buffer and check if a pixel color is between a color range, or not.
Maybe some code explains it better:
I have a buffer with 32Bits per Pixel (RGBA => R=8Bit, G=8Bit, B=8Bit, A=8Bit => 32Bit).
This buffer is... let's say 200x200 pixels.

// Defining color ranges
char redUpper = 100;
char redLower = 50;
char greenUpper = 150;
char greenLower = 130;
char blueUpper = 20;
char blueLower = 10;

//creating my pixel buffer
int* pBuffer = new int[200*200];
fillBufferWithData(pBuffer, 200*200); //some magic function the gets the image data into the buffer.

//analysing
char* pCursor = (char*)pBuffer;
for (int i = 0; i < 200*200; i++)
{
  //Every Pixel that is between the color range...
  if ((pCursor[0] > redLower) && (pCursor[0] < redUpper)
   && (pCursor[1] > greenLower) && (pCursor[1] < greenUpper)
   && (pCursor[2] > blueLower) && (pCursor[2] < blueUpper))
  {
    pCursor[3] = 0;
  }
  else
  {
    pCursor[3] = 255
  }

  pCursor += 4;
}
delete [] pBuffer;

Okay. I hope that helps to understand what i want to do. I know thats not the fastest way (at least I hope so). Maybe someone knows a better way, perhaps with bit-shifting, or bit-masking?

Thanks in advance,
SnowProg

Re: Bluebox - Chromakey etc

CPallini8-Oct-08 22:05

CPallini

8-Oct-08 22:05

Due to short-circuit of the boolean operations inside the if statement, the code is reasonably fast.
Maybe using three look-up tables will improve the code speed, but I'm not an expert.
Smile | :)

using x86 Windbg on x64 machine

George_George8-Oct-08 19:49

George_George

8-Oct-08 19:49

Hello everyone,

I found some weird issues when using x64 Windbg debugger to debug x86 binary on x64 machine, then I have tried to install x86 Windbg debugger to debug x86 binary on x64 machine, seem every weird issues is gone.

My questions,

1. Install two debuggers, Windbg x86 and x64 on one machine will be ok? No conflict?
2. Both debugger could automatically resolve system dependent resources -- for example, x64 debugger knows to load x64 system DLL and x86 debugger knows to load x86 system DLL, the same to registry settings?

thanks in advance,
George

prohbit shift key in edit box............

ani_ikram8-Oct-08 19:12

ani_ikram

8-Oct-08 19:12

how can i restrict user from pressing shift key in editbox ..
plz help me

Re: prohbit shift key in edit box............

Naveen8-Oct-08 19:22

Naveen

8-Oct-08 19:22

Can you tell us why you want to block it?

nave

[OpenedFileFinder] [My Blog]

Re: prohbit shift key in edit box............

ani_ikram8-Oct-08 19:29

ani_ikram

8-Oct-08 19:29

i want to make user to only input numbers (1 to so on) but not spectial charters using shift like (%,#,@,!,^,&,*,()) etc

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.