Ting 이네 Software 이야기

VC[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

__stdcall vs. __cdecl

refer below page..

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

* Making Blended & Clink-Through window

We can use following window style option at CreateWindowEx().
WS_EX_TRANSPARENT -> click-though
WS_EX_LAYERED -> alpha-blended window.

We can changne configuration in runtime by using following API.

SetLayeredWindowAttributes(...)
: Layered window's attributes (Alpha value, Transparet color etc) can be changed.

SetWindowLong(...)
: Window의 Ex Style can be changed. We can set or clear "Click-Through" by setting or clearing WS_EX_TRANSPARENT attributes.

* We can remove menu

by set 'lpszMenuName' as 'NULL' at 'WNDCLASSEX' structure when 'CreateWindowEx' is called.

* We can change initial background color of Window

by creating brush of preferred color at 'hbrBackground'.

* We can remove 'titlebar' and 'boarder'

by set 'dwStype' parameter as 'WS_POPUP' style.

* (Issue) Maximized window covers Taskbar!

We can resolve this issue by using 'WM_GETMINMAXINFO' and 'SystemParametersInfo/SPI_GETWORKAREA'.
('WM_GETMINMAXINFO' is sent when Window is moved or Window's size is changed.)

Let's put following code in the handler of 'WM_GETMINMAXINFO'.

MINMAXINFO* pi = (MINMAXINFO*)lParam;
RECT        r;
SystemParametersInfo(SPI_GETWORKAREA, 0, &r,0);
memset(pi, 0x00, sizeof(MINMAXINFO));
pi->ptMaxSize.x = r.right - r.left;
pi->ptMaxSize.y = r.bottom - r.top;
pi->ptMaxPosition.x = r.left;
pi->ptMaxPosition.y = r.top;

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Win32에서 IME가 Active되어 있으면, 즉 Imm context가 window handle에 associate되어 있고, 한글 입력모드에서 입력을 하고 있으면, WM_KEYDOWN의 wParam이 VK code가 올라 오지 않고, VK_PROCESSKEY가 올라온다. 즉 Imm이 해당 key를 processing하고 있다는 뜻이다. 여기서 어떻게 원래의 Key code를 얻어 올 수 있을까?

MSDN을 참조하면, "mmGetVirtualKey()"를 쓰면 된다고 하는데, 막상 써 보면, VK_PROCESSKEY가 그대로 return된다. 웹을 더 찾아보면, TranslateMessage를 호출하기 전에 사용하면 된다고 하는데, 안해 봐서 모르겠고, 또 그렇게 하기도 힘들다.

이럴때는 약간은 portability와 compatibility가 희생해서, scan code를 사용하는 방법이 있다.
몇몇 platform의 경우, (Embedded환경은 특히...) scan code가 전부 0으로 올라오는 경우도 있어서 100% portability가 떨어지긴 하나 어차피 100% portable은 존재하지 않으니까... :-)

scan code는 WM_KEYDOWN message의 lParam의 16~23 bit (8bit)인데, 이를 "MapVirtualKey()"함수를 사용해서 virtual key code를 얻을 수 있다.
뭐 일단 얼마나 portability가 희생되는지는 모르겠으나, 어느정도 잘 동작하는 것은 확인했다. 이 방법을 사용하는 것도 괜찮겠다.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

"WM_IME_COMPOSITION" 을 사용해야 한다.
뭐 MSDN을 찾아보면 관련 함수도 많이 나오고 설명도 많이 나오니 패스.
Font를 찍을 때는 TrueType의 경우, 그냥 GetWidth32W (32Bit 환경)을 써서 font width를 계산하면 된다.

몇 가지 주의할 점만 짚어 보겠다.
먼저 조합도중 Space입력.
이 넘이 상당히 많은 것을 자동으로 해 주어서 편하긴 한데, Asian국가중 힘 없는 한글은 상당히 무시되어 있다. ㅜ.ㅜ
젤 큰 문제는, 한글 조합도중 'Space'를 누르면, space가 Keycode로 올라와야 하는데, 이 Space는 그냥 "VK_PROCESSKEY"로 올라오고, "WM_IMM_COMPOSITION"에는 result로 space가 입력되기 전까지 조합되었던 글자가 올라온다. 즉, "WM_IME_COMPOSITION"만을 이용해서 한글 입력기를 만들게 되면, '가'를 입력하고(조합중) space를 치면, '가 '가 아니라 '가' 가 찍힌다. (Space가 나타나지 않는다.)
이를 처리해야 한다.!! (사실 일본어나 중국어의 경우 space는 character table을 보여주는 key로 사용되는 듯 하다. 그렇지만, 한글에는 그게 필요없으니.. MS한테 무시당했다...-_-;)

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Have you ever wanted to compile Linux binaries under Windows? This is how it

happens:
1. Get Cygwin setup.exe: http://www.cygwin.com/
1.1. Run setup.exe and continue to package selection list.
1.2. Under Devel catagory select tools you need for compiling your source. For example 'GNU make'.
1.3. Finish installing.

2. Get linux cross-compilers for cygwin:
"cygwin-gcc-linux.tar.bz2" (68.2 Mb). md5sum: 340e91a346f5bb17e660db10e43005b8
These compilers are made with crosstool 0.28-rc37. This package contains:
gcc-3.3.4 and gcc-2.95.3 for i386 (glibc 2.1.3) and gcc-3.3.3 for amd64
(glibc 2.3.2).

--------------------------------------------------------------------------------

Note! There is now newer version of GCC avaible with glibc 2.3.2:
"cygwin-gcc-3.3.6-glibc-2.3.2-linux.tar.bz2 (i386, x86_64)".
2.1. Copy 'cygwin-gcc-linux.tar.bz2' to 'c:\cygwin' or install directory which you selected in setup.exe.
2.2. Open Cygwin shell and change directory to root with 'cd /'.
2.3. Uncompress to Cygwin root with command:
'tar -jxvf cygwin-gcc-linux.tar.bz2'.

Cross-compilers are installed under '/opt/crosstool'. You can use them directly or with commands: gcc-linux, g++-linux, gcc-linux-2.95, g++-linux-2.95, gcc-linux-x86_64 and g++-linux-x86_64.

source : http://metamod-p.sourceforge.net/cross-compiling.on.windows.for.linux.html

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Error when executing shell command in "Cygwin make"
Here is the case.

path=c:\cygwin\bin; (...omitted... );; (...omitted...)

Take you attention to ';;' - two consecutive semicolon.

In above path environment, executable binaries like 'cp', 'mkdir' that are in 'c:\cywin\bin', works well. But, shell command like 'cmd' raise error something like "command not found".

After removing ';;' - consecutive semicolon (empty path) -, all works well.

So, here is my inference.

"Cywin make" executes command by following order.
  1. searching path environment to file executable binary.
  2. regards command as 'shell command' and try to execute.

In case that ';;' is appeared in the path, "Cygwin make" cannot recognize path after ';;'. So, executables located in the directory those are before ';;' works well. But, those are not, "Cygwin make" treats it as "shell command" and raises error (there is no shell command like this...).

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

▶ Performance gab between using 'enum' and "using '#define' in Visual C++ 7.0
Environment : CPU: Intel 2.8G

Using enum:
    Number of enum items := 100,000 -> compiling takes very long time.
    Number of enum items := 10,000 -> very quick.
Using define
    Very quick even if number of defined items reaches 100,000.

Experimentally, if number of enum items are larger than specific threshold, compiling performance of VC++ 7.0 drops dramatically. So in this case, we would better to change 'enum' into '#define'.

▶ Order of finding 'include directory' in VC++ 7.0
"highest priority is directory where currently issued file is in.".
For example, lets consider following directory structure.

directory : xxx/src
=> a.c, c.h
directory : xxx/inc
=> b.h, c.h

(Let's assume that "xxx/inc" is added at "additional include directory").
"xxx/inc/b.h" and "xxx/inc/c.h" is used to compile "a.c". Even though compiler try to compile "a.c", "b.h" is issued file during parsing "b.h". And, "b.h" includes "c.h". So "c.h" in the directory where "b.h" is in, is included, because currently issued file is "b.h".

▶ Case that '.c' file and '.cpp' file whose basename are same, are in one VC Project in Visual 2005 Express C++.
For example, if there are 'a.c' and 'a.cpp' in one project, MSVC recognizes only '.cpp' file (based on experimental result). (I think the reason is that default compiler of VC is 'cpp' compiler.)
So, even if we modify 'a.c' and build, nothing is compiled because MSVC keep it's eyes on 'a.cpp' - it is not changed. (--> It's MSVC's bug!!)

▶ There is no way to compile one file with several different options in VC project. So we should use 'command line' to do this.