아는 사람은 다 알고 있겠지만 explorer mini와 arc mouse 즉, MS의 최신 무선 마우스들은 비스타와 7에서 휠이 마우스 설정과 따로 논다.
XP에선 문제가 없고, MS의 다른 유선 마우스들은 제대로 동작한다. 다른 무선 마우스들도 제대로 동작안한다는 경우가 있다고 하나 안써봐서 모른다.

휠 설정을 8라인씩 해놓아도 1라인씩 갈 수도 있고, 정반대로 심하게 많이 이동할 수도 있다.
후자의 경우는 경험상 USB 리시버를 뺐다가 다시 꽂으면 제대로 작동하곤 했다.

이를 해결하기 위한 첫번째 방법은 레지스트리 설정 변경이다.
HKEY_LOCAL_MACHINE->SYSTEM->CurrentControlSet->Enum->HID->VID_045E&PID_xxxx&MI_xx&Colxx->Device Parameters에 다음의 두가지 DWORD 엔트리를 추가한다.

HScrollHighResolutionDisable=1
VScrollHighResolutionDisable=1

위의 PID, MI,Col은 시스템마다 다를 수 있으니 자신의 마우스 등록정보를 확인한다.

또한, 위의 설정을 적용하면 마우스 설정에서 휠 감도를 줄여주는 것이 좋다. 안그러면 휠이 미친듯이 동작하는 것을 확인할 수 있다.

두번째 방법은 Sleep Mode에 들어갔다 나온다. 이유는 모르겠지만 Sleep Mode에 들어갔다 나오니 마우스 설정대로 휠이 동작한다. 첫번째 방법인 레지스트리 변경 적용후 Sleep Mode에 들어갔다 나오니 갑자기 휠이 매우 세밀하게 움직였다. (마우스 설정은 수직1, 수평1로 조절한 상태였음. 위의 레지스트리 적용시 이정도가 휠의 감도가 적절했다) 이걸보고 혹시나 하는 생각에 수직8, 수평3으로 변경하니 내가 원하던 감도를 얻을 수 있었다.
지금의 감도가 레지스트리 변경과 Sleep Mode 진입이 둘다 영향을 미치는 지는 알 수 없지만 어쨌든 Sleep Mode 들어갔다 나오니 감도가 유선 쓸때와 동일하게 나오는 건 맞는 듯 하다.

거의 2~3시간 삽질한 결과가 다소 허무하게 끝남.

Word 2007/Vista의 고질적인 문제였던 워드 파일을 열때 열수 없다는 오류 발생에 대한 Fix를 Microsoft에서 공개했다. 문제가 발생안하면 좋은거고 자동 업데이트 수행후 이런 문제 발생했을 경우 적용하라고 되어있다.
그리고 해보니 잘 된다.
링크는 아래에 있으며 한글버전은 따로 있지 않을까 생각함

http://support.microsoft.com/default.aspx?scid=kb;en-us;940791

MS Word 사용시 잘되던 붙여넣기 기능이 갑자기 매크로를 사용할 수 없다고 나오면서 안되는 경우가 있다. 원인은 여러가지가 있을 수 있으나 그 중의 하나의 원인은 Mathtype을 설치한 경우 발생한다.

Word에 Mathtype을 설치한 경우 Word에서 Mathtype을 쓰기 위해서는 Mathtype에서 등록한 매크로를 허용해야 쓸 수 있다. 실제로 Word 2007의 경우 Mathtype 리본 탭이 매크로를 허용해야 사용가능하도록 표시된다. 그리고 Mathtype의 개발사인 Design Science 측에서는 매크로 허용시 Design Science의 모든 매크로를 허용할 것으로 권장하고 있다.

이 것이 매크로 허용과 관련되어 있고, 또 저 오류 메시지도 매크로 허용 문제를 언급하고 있는 것으로부터 붙여넣기가 안되는 것이 이 Mathtype의 매크로 허용과 관계있는 것이 아닐까라는 생각을 우연히 하게 되었다. (물론 Mathtype이 설치되었음을 확인한 후에 이런 생각을 하게됨)

그러므로 해결방법은 쉽게 알 수 있다. Word 시작시 Mathtype의 매크로를 허용하지 않았다면 매번 매크로 허용 여부를 물어볼 것이다. 이때, Mathtype 매크로를 허용(Design Science의 매크로 모두 허용)하는 것으로 문제는 해결될 수 있다.

그러나 이것은 한가지 방법일 뿐이고 모든 경우에 적용된다고 보장할 수 없다.
나는 아직 이런 메시지를 겪지 못해서 말이지;;

Windows mail 사용시 메일 메시지를 클릭시 다음과 같은 내용이 나오면서 삭제가 안되는 경우가 있다.
This mesage cannot be displayed.
The message also says it may be due to low
memory or disk space but there is plenty of both.

내 경우는 Windows 2008의 Windows mail을 디렉토리 전체를 백업한후 Vista를 설치한 후 Windows mail 폴더 자체에 덮어 씌운 경우 이런 일이 발생했다.

물론 메모리나 디스크 용량 문제는 아니었다.

이유는 잘 모르지만 해결책은 의외로 간단했다.

다음의 업데이트를 설치하면 삭제가 되지 않는 문제는 해결된다.
http://support.microsoft.com/default.aspx/kb/941090

물론 이 경우는 해당 메시지가 필요없는 경우나 해당 메시지가 두개 이상 있어 그중 하나에 대해 위와 같은 메시지가 출력되는 경우 위의 메시지를 지울 경우에 해당된다.
그리고 내 경우는 Windows mail을 복원한 후 처음으로 Windows mail을 킬 때 에러가 나고, Windows mail을 닫았다가 다시 킨 경우 일부 메시지에 대해서는 정상적으로 메시지가 표시되고 그에 대해 복제된 메시지에 대해 위와 같은 메시지가 출력되는 것을 확인할 수 있었다.
따라서 이런 경우는 위의 방법이 적용가능한데 만약 정상적으로 사용중에 갑자기 이런 메시지가 표시되는 메일이 있다면?

글쎄올시다. 아직 그런 일이 발생하지 않아서 -_-;;

그동안 Vista에서 정말 지독할 정도로 자주 일어나는 Webdav 사용시 Freeze 현상때문에 별짓을 다했었다.
포맷도 여러번 했고, Windows 2008도 깔아보고 그러나 결론은 내지 못했었다.

우연히 한번 정도 이상없이 썼던 적을 제외하고는 모든 경우 Freeze 현상 발생.
별의별 업데이트도 깔아보았지만 해결하지 못하였고, 이 문제 때문에 Vista를 어느 날 깔고 그 다음날 다시 깔기 까지 해보았다.

우연히 해결책을 찾은 듯 하다.

그동안 대부분의 경우 백신 프로그램으로 Eset Smart Security를 깔아서 사용을 했었다.
그리고 대부분 Freeze 현상이 예외없이 발생했다.

그러다 어제 연구실 PC에 Vista를 깔면서 혹시나 하는 생각에 ESS를 깔지 않고 사용을 해보았다.
언제 그랬다는듯 이상없는 Webdav.

현재까지 이상없는 것으로 볼때 문제의 원인은 ESS의 실시간 감시 기능과 관련이 있는 듯 해서 옵션을 뒤적거리거다 아래와 같이 Network drive에 대한 실시간 감시 기능을 꺼보았다.

그랬더니 언제그랬냐는듯 이상없이 Webdav 사용가능.

아직 충분한 테스트를 거친건 아니지만 아무래도 이 옵션 때문에 그동안 잘 안되었던 것으로 생각된다.
드디어 스트레스를 덜 받을 수 있을 듯 하다.

Windows mail은 아시다시피 Windows Vista 및 Windows Server 2008 제품군에 포함된 메일 클라이언트 프로그램이다. (2008의 경우는 Server Manager에서 Desktop Experience를 설치해야 비로소 사용가능하다)

메일 클라이언트이므로 첨부파일의 저장 및 보기 기능이 당연히 포함되어야 하고 포함된다.

그런데 이 기능이 Office Outlook 계열에서의 경우와 약간 달라서 약간 불편하다.
즉, Outlook에서는 저장시 파일 이름을 내 맘대로 바꿀 수 있었던것으로 기억하는데 기본적으로는 파일 이름 변경하는 기능을 찾기가 어렵다. (심지어 처음에는 폴더 지정시 새로운 폴더를 만드는 옵션도 찾지 못했었다)

그런데 오늘 우연히 해결책을 찾았다.

Windows Mail에서는 기존의 Outlook Express 계열과 동일하게 첨부파일이 포함된 메시지의 경우 클립 모양을 클릭하게 되면 저장 또는 열기 옵션이 나오게 되고 여기서 저장 버튼을 누르면 저장을 원하는 위치를 지정한 후 저장하게 된다.
앞에서 말한바와 같이 기본적으로 여기서는 파일 이름의 변경이 불가능하다. (또는 단지 기존에 이 옵션을 찾지 못했을 따름일 수도 있다)

이를 해결하기 위한 방법으로는 클립 모양의 첨부파일 클릭시 왼쪽 마우스가 아닌 오른쪽 마우스를 이용한다. 그러면 왼쪽 마우스로 클릭했을 때와 마찬가지로 첨부파일 이름 및 저장 옵션이 나타나는데 이때 저장하기가 아닌 파일이름을 왼쪽마우스로 클릭한다.
이경우 위에서와 달리 Windows Vista 또는 Windows Server 2008에서의 기본 파일 저장할 때의 화면이 나타나는 것을 확인할 수 있고, 물론 이 때 파일 이름 변경 및 폴더 생성, 삭제 등이 가능하다.

이전 버전에서도 이랬었는지 기억은 안나지만 0.95 버전을 쓰다보니 이상하게도 태그도 동일가수, 동일앨범으로 되어 있고, 하나의 폴더 안에 들어있는 음악 파일들이지만 곡에 따라 앨범 커버 이미지가 다르게 나오는 파일들이 있었다.
그리고, 개개의 파일들에 대해서는 동일한 앨범 이미지가 나오지만 해당 앨범 전체를 클릭하면 앨범 이미지가 표시되는 부분에 [multiple items] 라고 표시되고 이미지가 표시되지 않는 경우도 있다.
(이러한 메시지는 보통 서로 다른 앨범 이미지를 가지는 여러 앨범을 동시 선택한 경우 나타난다.)

여러번의 삽질끝에 해결방안을 발견했으니 그건 앨범 이미지가 꼬이는 앨범에 대해 태그 지우고 다시 설정하라는 것 정도.

# 08/02/09 추가사항
단순히 태그 지운후 다시 설정하는 것으로 해결이 안되는 경우도 있는데 이경우는 태그 타입에 ID3v1,ID3v2가 모두 설정되어 있는 경우 하나만 체크하면 해결되는듯하다. ID3v2 체크를 지우니 잘됨.

이것이 현재 Foobar 0.95 버전의 문제인지는 잘 모르겠다만 여하튼 불편한건 사실이고, 이렇게 하니 앨범 이미지가 제대로 나온다.

개인적으로 이전 버전에서처럼 앨범 이미지가 나오는 부분에 앨범 이미지 경로가 나타나는 것이 좋은데 아쉬운 점. 이런 경우 최소한 앨범 이미지가 엇갈리는 경우 어느 경로의 이미지를 이용하는지는 알 수 있을테니 말이다.

Visual Studio에서 Build를 시도하면 간혹가다가 위 제목과 같은 메시지가 뜨는 경우가 있다. 물론 한글버전에서는 한글로 나온다. 저 경우는 단지 경고 또는 정보 제공의 수준이고 오류는 아니라서 무사히 Build는 되지만 왠지 찝찝하다.
이를 해결하기 위해서는 해당 프로젝트의 Debug 디렉토리를 지운 후 다시 Build 시도하면 저 메시지가 안뜬다고 함. 해당 프로젝트에 대한 Debug 디렉토리는 프로젝트 자체의 Debug 디렉토리가 있고 또 솔루션의 Debug 디렉토리가 모두 존재할 터인데 프로젝트의 Debug 디렉토리만 지우면 되는 듯 함.(상위 디렉토리)
그게 아니고 솔루션 Build시에는 솔루션 Debug 디렉토리, 프로젝트 Build시에는 프로젝트 Debug 디렉토리일 수도 있음..(단일 솔루션 프로젝트인 관계로 확인못함)

이게 과연 맞는 팁이 될런지 모르겠다. 그리고 일반성도 떨어지는 측면이 적지 않다.
하여튼, 나와 같은 증상을 가진 사람이라면 한번쯤 시도해서 나쁠 일은 없을 듯 하다.
언제부터인가 Foobar를 열게 되면 별다른 이유없이 시스템이 다운되는 일이 잦아졌다. 이는 현재 사용중인 세개의 시스템에서 공통적으로 발생한다. 다만, 듀얼코어 시스템은 사용한지 얼마 안되서인지 시스템 내부의 먼지도 거의 없고 해서 불시 다운될 가능성이 적기 때문인지 아니면 듀얼 코어 컴퓨팅 파워 때문인지 한번 다운 되었다. 그리고 집에서 사용중인 데탑은 최근 한달동안(아니면 그보다 더 오랜기간) 쉴새없이 많이 Foobar를 열때 다운이 되곤 했다. 그나마, 다행인 점은 약 1주전까지만 해도 꼭 이 Foobar때문이 아니더라도 PC를 끄지 않고 자면 아침에 일어나면 거의 언제나 시스템이 뻗어있고, 가끔 시스템 부팅할때도 하드를 인식하지 못해 부팅을 하지 못하거나 시스템이 뻗는 상황이 발생해 전원을 끄고 다시 키는 방법을 써서 간신히 부팅을 하곤 했었는데 최근에는 그런 일은 발생하지 않았다.
그리고 노트북의 경우 대개 Foobar쪽에서 다운이 되고 듀얼 코어의 경우와 마찬가지로 나머지 경우는 별 이상없이 사용중이다.
세 PC모두 설치되어 있는 프로그램은 거의 비슷하고 그것이 한두개가 아니므로 원인을 찾기는 어렵지만 일단 Foobar창을 여는 경우 시스템이 다운되므로 Foobar내부에서 원인을 찾아야 하는데 예전에 별문제없이 쓸때와 차이점을 찾아본 결과 생각나는건 단 하나, 푸바내의 글꼴을 Segoe UI로 바꾼 것이다. Foobar 기본 설정하에서는 MS Shell Dlg이다. 이 둘의 가장 큰 차이는 XP부터 도입된 Cleartype의 적용 여부이다. 아는 사람은 모두 알고 있듯이 Segoe UI는 Calibri를 비롯한 여러 글꼴들과 더불어 Vista/Office 2007에서 적용되기 시작했고 Vista의 기본 글꼴로 설정되어 있다.(영문버전의 경우) 그리고 가장 큰 특징으로 Cleartype 기반으로 Cleartype을 설정하지 않은 경우 매우 보기 싫게 나온다. 반면, MS Shell Dlg 폰트의 경우 기존 95,98 아니 그 이전부터 존재하던 폰트로 추정되며(3.1시절의 MS Sans Serif와 매우 닮아있다) Cleartype이 적용이 되는지 안되는지 모를 정도로 별 영향을 안받는 것 처럼 보인다.
그런데 생각이 여기까지 미치자 떠오르는게 있었으니 예전에 듀얼 코어 초기에 듀얼 코어를 사용할때 Windows 고전 테마에 Cleartype을 적용한 경우 시스템이 다운되는 버그가 있었다는 것이다. 지금 난 고전 테마를 적용한 시스템이 아니라서 이게 별 상관이 없을 수도 있겠으나 아무래도 Cleartype이 적용되는 Segoe UI를 Foobar의 기본 글꼴로 설정해서 Foobar를 열때 시스템이 다운되는 현상이 자주 발생하는 것이 아닌가 하는 생각이 들었다. 그래서 일단 글꼴을 원래대로 설정해보니 아직은 별다른 문제가 보이지 않는다.
아무래도 Cleartype과 관련된 문제는 거의 확실해보이는데 세 시스템 모두 프로세서가 셀러론,펜티엄4, AMD 애슬론64 X2로 각각 달라서 프로세서의 문제로 치부해버릴 수도 없고 정확한 원인은 미지수.....
그리고 왜 최근에서야 다운현상이 잦은지도 이해가 잘 안간다. 예전에 노트북에 비스타 깔고 쓸대도 Foobar사용 관련해 다운된 적은 한번도 없었는데 말이다. 다만 시디롬 읽다가 다운된 적은 몇번 있었지만 말이다.

결론은 Cleartype을 사용하지 않거나 Cleartype이 적용되지 않는 글꼴을 사용해보라는 것!

Microsoft Office 2007 보다 정확하게는 Excel 2007을 사용하는 대부분의 사용자가 겪으면서도 그 원인을 알기 힘든 문제중의 하나가 바로 언제부터인가 엑셀이 실행되지 않은 상태에서 탐색기 등의 외부에서 엑셀 파일을 실행시키면 엑셀이 먼저 실행된 후 몇분이 지나서야 파일을 읽는다는 것이다. 그리고 단지 엑셀을 실행하는데는 시간이 그리 길게 걸리지 않고 엑셀이 실행된 상태에서는 외부에서 읽든 엑셀내부에서 읽든 빨리 파일이 읽힌다.

이에 대한 해결책으로는 여러가지가 전해내려온다(?)
가장 먼저, 레지스트리 및 기타 설정 변경없이 임시방편으로 빨리 읽어들이는 방법으로 엑셀이 실행된 후 메뉴에서 오피스 메뉴를 클릭한 후 서브 메뉴를 가진 활성화된 메뉴 즉, 보내기 등과 같은 메뉴에 마우스를 갖다대면 잠시후 서브메뉴가 오른쪽에 표시되면서 파일이 읽힌다.
이는 윈도우상에서 다운로드 속도가 느리거나 할때 마우스를 빙빙 돌리면 속도가 빨라진다는 그런 것과 비슷한 맥락에서 생각할 수 있는 것 같다. 자원 우선순위를 먹는 뭐 그런것과 관련..

그리고 두번째로 이것이 가장 널리 알려진 방법이다. (우리나라 사이트들에서는 찾지 못하고 구글링을 해보니 외국 사이트들에서는 대개 이방법을 해결책으로 내세우고 있었다.) 탐색기에서 엑셀파일 확장자인 xls 그리고 xlsx파일의 파일형식의 고급에 들어가서 열기에 대해 편집에 들어가면 열기 실행할때 사용되는 프로그램에 엑셀의 경로가 나오고 그 뒤에 /e 옵션이 붙어있다. 이 뒤에 "%1"을 붙인 후 종료한다. 내 경우는 이 방법을 시도해본 결과 엑셀에서 열리기는 빨리 열리지만 엑셀을 종료하고나면 파일을 찾을 수 없다는 에러메시지가 표시되었다. 이것이 내 경우만 이런것인지 원래 이런것인지는 알 수 없지만 복구를 두번이나 했음에도 같은 현상이 발생함에 따라 이방법을 결국 쓰지 않게 되었다.

마지막 방법은 처음부터 의심했던 방법을 실행에 옮긴 것인데, Office 2007이 여러번의 보안업데이트를 거친 후부터 워드에서는 실행할때마다 매크로가 차단되었다는 메시지가 뜨며 최근실행파일에 Cleaner.dot / Cleaner.xla파일이 각각 워드/엑셀에서 나타난다. 그리고 차단되었다는 매크로는 Cleaner.dot파일. 알아보니 이들은 자동 복구 관련 Addin파일이라고 하며 오피스 Startup 디렉토리에 있는관계로(xla파일의 경우는 Xlstart 디렉토리) 오피스의 각 프로그램이 실행될때 자동으로 실행된다.(파워포인트의 경우는 Cleaner.ppa) 그런 관계로 엑셀의 경우 이 파일을 먼저 읽게 되어 파일을 읽는데 시간이 지연이 되는 것으로 보이며(vba 들어가서 내용을 확인한 결과 델타그래프를 깐 이후 내용이 좀 이상하게 변했다) 워드의 경우는 이 파일을 기본적으로 안 읽어서 파일을 읽는데 지연이 일어나지 않는것으로 보인다. 그리고 파워포인트는 읽지만 파일 읽는데도 그렇게 느리지 않는다. 이유는 모른다. 어쩌면 내 경우는 xla의 경우는 델타그래프를 설치한 후 그 내용이 변해있는 것과 관련이 있는지 모른다. 자동복구 관련이라고 했고 델타그래프 설치한후 엑셀에서 자동복구가 실행된 적이 몇번 있으므로.. 많은 사람들이 같은 현상을 겪고 있는건 잘 모르겠지만 어쨌든 내 경우는 이 세 파일들을 모두 지워보니 별 이상없이 잘 로드되었다. 다만, 파워포인트에서는 이 파일 없다고 나왔으나 귀찮아서 Cleaner.ppa 파일 관련 레지스트리 지워주니 에러 없이 잘 된다. 이로써 자동복구가 안될지는 모르지만 그러면 나중에 포맷하고 다시 설치해볼 생각이다. 어쨌든, 결론은 Cleaner.xla 파일을 지우거나 Xlstart 디렉토리에서 다른 것으로 옮기라는 것.