:  작업환경 저장 기능에서 때때로 오동작을 보입니다.
:  창 위치가 변경된다든가, 크기가 틀려질때는 다시 save를 해야합니다.

그런 경우는 저도 몇번 봤습니다만, 전 별로 신경을 써보지 않아 생각을 못했었군요.


:  간단한거로는 TODO LIST 엉키는 문제나 Undo 완전 날아가는 문제 ....

저는 To do 리스트를 전혀 쓰지 않고 모두 주석으로 처리해왔기 때문에 그에 대해선 뭐라고 할 말이
없구요. Undo는 제 경우엔 꽤 많이 쓰는 편인데.. 날아가는 문제는 아직 겪어보지 못했기 때문에
역시 할 말이 없군요.


:  코드 에디터의 Alt+Shift 선택 기능.. 역시 마우스를 클릭해줘야 원상복귀 되는..
:  버그가 그대로 있습니다.

아래 해당화님이 답변하신바와 같습니다.
추가로 빌더의 핫키 리스트를 보시려면 제가 1년쯤 전이던가 Tip 게시판에 올려놓은 것이 있습니다.
(그 외에도 상당히 더 있는데.. 예전에 게시판 포팅하면서 첨부했던 파일 몇개가 날아가버렸군요.)


:  코드자동완성과, 패러미터 표시기능이 빨라졌다고 좋아하시는분이 많은데..
:  역시 저는 아직 만족하지 않고 있습니다 VC++에 비하면-_-느린거죠.
:  패러미터 표시기능은.. 트라이얼이라서 그런건지 모르겠지만..
:  WINAPI는 아예 표시도 안되더라구요...

말씀하신 것은 코드 인사이트 중 코드 파라미터 기능입니다.
그리고 제가 써본 바로는 VCL 함수들 뿐 아니라 Win32 SDK 함수들도 잘 되고 있습니다.
만약 안되는 것이 있다면 해당 헤더 파일을 인클루드를 안하셨을 가능성이 크겠지요.


:  또 코드 입력중에 캐스팅을 비롯한-_-조금만 정직하지 못한 코드를 입력하면..
:  패러미터창이 사라져서 다시 Ctrl+Shift+Space를 눌러줘야되죠-_-

제 개인적인 생각이지만, 볼랜드와 MS의 철학의 차이라고 보이는데요.
C++에서는 오버로딩이나 네임스페이스 때문에 동일한 함수 이름이 이미 존재하거나 개발자가 스스로
존재하는 함수와 동일한 이름의 함수를 만들어쓰게 되는 경우가 종종 있으므로, 거기서 개발자에게
어느 정도의 자유도를 주느냐 하는 문제로 보입니다. 적어도 버그라고 부를 것은 아니지요?


:  옵션 설정에 있어서는..컬러설정이 가장 마음에 안드는군요.
:  전 마우스 사용하는거 상당히 싫어합니다 -_-
:  물론 생각의 차이는 있겠지만..
:  컬러 설정 하는데 제가 생각하는 '볼랜드'가 마우스를 주 조작으로 이용하게 했다는것..
:  이 참 맘에 안듭니다.
:  빌더 새로 깔고 셋팅하는데 4-5분은 걸리지요.

말씀하신대로 개인적인 선호도의 문제겠지요? 새로 깔 때마다 설정을 다시 하는 것이 번거로우시다면
레지스트리의 HKEY_CURRENT_USER\Software\Borland\C++Builder\(버전)\Editor\Highlight 키를 몽땅
파일로 저장해뒀다가 복구하면 됩니다. 이곳에 모든 컬러 설정 정보들이 저장됩니다.


:  멀티쓰레드 프로그래밍이나 프로세스 관련 프로그래밍을..빌더에서 하기가 힘듭니다.
:  ALT+T, D 의 디버그 옵션에서 Messages의 항목을 전부 켜시고.
:  Ctrl+Alt+V 의 Event Log를 켜신다음.. 기존에 작업중이던 아무 프로그램이나 실행하면..
:  켤때 먹통 되거나, 끌때 먹통됩니다.
:  아는분께서 일부 시스템에서 그런다는데 -_-
:  P3 550, 램256에서도 그랬고..
:  애슬론 866, 900, 1200...과 (램은 모두 512)
:  저와 함께 스터디 하는 친구들이나 대부분의 아는사람은 모두 같은 현상이 일어납니다.
:  혹시 이게 '일부'에 속하는거라면 좀 그렇죠 -_-;;
:  혹시 테스트용 버전이나, 정품과 트라이얼과는 버그수준이 다른거라면 모르겠네요...

생각해보니 제 경우에도 그런 일이 몇번 있었던 것 같군요.
방금 해보니 이벤트로그 옵션에서 다른 체크박스는 상관없는데 "윈도우 메시지"를 체크해놓으면
디버깅이 끝날 때 빌더 IDE가 죽어버리네요. (이벤트로그 창을 띄웠건 안띄웠건 상관이 없음)
확실한 버그군요.


:  ActiveX로는.. 프로젝트명 변경시 충돌로 컴파일이 안되는것과..
:  Type Library 수정과, 코드 입력할때 자동으로 완성되는 코드가 덜 들어가서-_-
:  컴파일 안되는 것 때문에 프로젝트 매번 폴더 단위로 복사해 뒀다가;
:  에러 뜨면 지우고, 다시 대체해서 작업하던 것들.

빌더의 액티브X 지원은 많은 분들이 문제를 지적하셨던 부분입니다.
6 버전에서 이 부분이 해결되지 않은 것은 저도 아주 불만스럽습니다.


:  이건 제대로 테스트 해보지 않은건데 무슨 옵션을 변경해야 할지도 모르겠네요
:  사용자 컴포넌트를 사용할때.. 빌더5까지는 bpl인가만 있으면 된다고 알고 있는데..
:  빌더6에서는 LIB을 요구하더군요..
:  그래서 컴포넌트 옵션에 LIB생성 옵션을 켰더니 생성이 안되더라고요 -_-
:  기존 프로젝트가 LIB가 없다면서 컴파일이 안됩니다.

bpl만 가지고 빌드되는 컴퍼넌트는 없습니다. lib 외에도 obj, 헤더파일 등이 필요합니다.


:  컴파일 되다 다운되는 경우는 저도 딱 한번 있었으나-_-이런건 이해가 됩니다.
:  링크 엉키는거나..이런것도 build all 이 해주니까-_-넘어갈수 있구요..

가끔씩 링크가 엉키는 것은 빌더가 기본적으로 인크리멘털 링킹을 하기 때문에 생기는 문제입니다.
물론 개선이 불가능하지는 않을 것이고, 저도 개선되었으면 좋겠습니다.
하지만 역시 말씀하신 것처럼, 심각한 문제는 아니네요.


:  프로젝트를 불러오거나, 빌더를 끌때... 어떤 상황인지는 잘 모르지만
:  빌더관련 bpl들을 표시해 주면서 에러가 끝없이 뜨는 경우도 있습니다.

무슨무슨 bpl을 찾을 수 없습니다..는 식으로 뜨는 에러 말씀이신가요?
해당 프로젝트를 작성할 때 깔아놨었던 서드파티 컴퍼넌트 패키지가 현재 존재하지 않기 때문입니다.
해당 패키지를 다시 설치하든지, 아니면 프로젝트파일을 열어서 해당 파일을 지정한 부분을
지워주든지, 그도 귀찮으면 에러메시지가 뜨면서 "메시지 계속 볼래?" 할 때 No를 선택하면 됩니다.


:  그리고 전 언어만 아는 사람은 프로그래머라고 생각해 주지 않습니다.
:  모든 툴을 능숙하게 다루고, 뭐 부품사다 조립하고 바이오스 업데이트는 요새 다들 하시던데;
:  윈도우도 못깔고 셋팅도 못해주고, 트레이 아이콘이 10개씩 떠있고, 레지스트리는 지저분하고...
:
:  그런생각을 갖고 있는 저라서..제 시스템에 안정성이 없다고 생각하진 않습니다.
:  컴퓨터도 저사양인 편은 아닙니다. 무난하다고 생각합니다.
:
:
:  자부심이 대단한 볼랜드 직원들이 왜 MS로 갔던걸까요 -_-;
:  이건-_-농담이고-_-;;

사람이 자부심만으로 사는 건 아니니까.. 그리고 자부심의 종류도 다양하니까...
(저도 지나가다 적어봤습니다.)


:  제가 말하는 자부심은 개발자로써의 자부심이라는건 아실껍니다.
:  조그만 버그 하나도 용납하지 못하고, 최대한 편리한 인터페이스를 제공하겠다는것이
:  자부심 있는 개발자의 기본이라고 생각합니다.
:
:
:  또 성의가 없다고 했는데..
:  새로운걸 만드는건 재미있는 일입니다.
:  유지보수는 상당히 재미없는 일이구요...
:
:  3.1방식의 헬프..처음엔 가볍다고 생각하고 쓰자..라고 해지만..
:  빌더6의 헬프는.. 모습만 그대로가 아닙니다.
:  내용도 빌더5 그대로 입니다.
:
:  예를들면..
:  SetLayeredWindowAttributes()같은 함수는 헬프에 없습니다.
:  Windows개발툴이면서 Windows API가 없다는건 잘못된 겁니다.

말씀하신대로 빌더6의 Win32 SDK 헬프는 빌더5에서 제공했던 그대로입니다.
더 정확히 말하자면, 빌더1에서 제공했던 그대로입니다.

Win32 SDK 헬프, 그리고 관련 헤더와 라이브러리는 볼랜드에서 만든 것이 아닙니다.
MS에서 윈95를 내놓은 직후에 공개했던 Win32 SDK를 라이선스한 것입니다.

볼랜드에서는 MS가 만든 Win32 SDK를 라이선스해서 그대로 실었을 뿐, 거기다 내용을 추가하고
할 권한은 없습니다. 새로운 버전을 탑재하지 못한 것은 볼랜드가 돈 문제로(?) 새로운 버전을
라이선스하지 못했을 수도 있고, 아니면 전략적인 이유로 MS에서 허용하지 않았을 수도 있겠습니다.

윈도우 개발툴에는 윈도우 API에 대한 최신 헬프를 탑재하지 않는 것은 잘못된 것이라는 것은 님의
개인적인 생각일 뿐입니다. 로레벨 코딩을 많이 하신다니 아시겠습니다만, 도스시절의 터보C나 볼랜드C++,
그리고 DOS를 팔고 있던 MS의 MS C에조차도 지금의 API에 해당하는 인터럽트 헬프는 없었습니다.
(오히려 당시에는 볼랜드가 뛰어난 헬프로 이름을 날리고 있었고, MS C에는 헬프가 아예 없었습니다)

또한 비주얼C++에 익숙하시다보니 그런 불만을 가지시게 된 것이겠지만, 윈도우는 분명 MS의 저작물이고,
리눅스와 같이 일정 조건만 갖추면 누구나 관련 문서를 배포할 수 있는 것이 아닙니다.
어떻게 보면 그런 점들이 MS의 비신사적인 마케팅 중 하나라고 할 수 있는데, 플랫폼과 개발툴은
분명히 별개의 제품임에도 불구하고 모든 플랫폼 관련 API를 개발툴을 통해서만 발표해왔지요.

그리고 Win32 SDK 헬프를 제외하고 빌더 자체의 헬프는 끊임없이 개선되고 있습니다.
그 속도가 만족스럽지 않으실 수도 있겠습니다만.


:  WinSight나 Database DeskTop 역시 마찬가지..
:  DD는 그렇다 치더라도 WinSight는 아직 수정되야할 내용이 많습니다.

윈사이트는 95년이던가 96년의 볼랜드C++ 5.0에 포함되었던 것을 그대로 같이 배포하는 것입니다.
다시 말하면, 원래부터가 빌더에 포함하기 위해 만든 아닙니다. 그걸 끼워넣은 것이 잘못이라면 잘못이겠지요.
데이터베이스 데스크탑의 경우엔, 어느정도는 볼랜드가 고의적으로 BDE에 대한 지원을 점점 줄여가고
있기 때문일 거구요. 이것은 98년이었던가에 마지막으로 약간의 패치를 한 것이 마지막입니다.


:  그리고 빌더5 이후 추가된 엔터프라이즈급 기능들..
:  제게 도움은 안되지만 저도 뒤쳐지는 개발자는 싫어하므로..
:  빌더5에서 제공하는 대부분의 기능은 한두번씩 다 해봤습니다.
: 
:  빌더6도 해봐야 하지만-_-그러고 싶은 마음이 안생기네요.
:
:  ActiveX나 웹개발도 컴포넌트 개발도 2년 가량 해봤고.. WAP도 해보고. DB도 해보고..
:  아예 모르면서 무조건 나쁘다 나쁘다 한다는 입장은 아닙니다.
:
:  ActiveX를 제작해도 클릭하고 덧붙이는 코딩하는걸로 끝나는게 아니라
:  내부도 다 살펴보고, 순수하게 코딩만으로 구현할줄 알아야 안심이 됩니다.
:
:
:  사소한것 하나하나, 기본이 바로서지 못하면 곧 무너지게 됩니다.
:  빌더8~9쯤 되면.. 'C/C++을 기반으로 한 살짝 추가해주는식의 코딩의 툴'이 될지도 모르고.
:
:  그렇게 되면 기반 프로그래머들에게 외면당하게 되는겁니다.
:  망하지는 않겠지만... 본래의 색을 잃어버릴지도 모르겠네요.
:
:  볼랜드의 전략이 그거라면 볼랜드를 숭배(-_-)해온 제가 안타까워 지기도 하구요...
:  [생산성, RAD이런 얘기까지 넘어가 버리면 끝이 없겠네요;]
:
:
:
:  생각없이 썼던글 죄송한 말씀 드리고..
:  기대가 크면 실망도 크듯이..
:  제가 왜 이런글을 써야하는지 아실꺼라 생각합니다.
:


님께서는 그동안 개발을 해오시면서 나름대로 터득하신 개발의 도가 있다고 느껴집니다.
그리고 저도 K&R 원서 하나만 달랑 가지고 C를 시작한지가 올해로 12년째입니다.
부끄럽지만 애플베이직으로 알카노이드나 만들던 때로부터 따지면 16년입니다.
그래서 미흡하나마 저에게도 개발은 이러한 것이라는 개념은 있습니다.
그리고 나름대로 경력 개발자라고 생각하시는 분들이라면 기본적인 정도야 없겠습니까.
하지만 그런 생각들은 모든 개발자마다 다 다른 것입니다.

최대한 로레벨까지 동작원리를 이해해야만 안심이 된다는 투철한 정신에는 박수를 보냅니다.
그리고 저 역시 그런 사람들 중의 하나이고, 그래서 빌더의 경우에도 첫 버전부터 매 버전마다
거의 대부분의 VCL 코드를 살펴봅니다.
하지만 그것만이 유일한 길이라는 생각은 오히려 위험하다는 것이, 역시 "개인적인" 제 생각입니다.

분명한 것은, C++Builder가 처음 출시된 이후로 매번 버전업때마다 가장 우선적으로 중점을 두고
있는 것은 님께서 그토록 열망하시는 "작은 편의성"이 아닙니다.
볼랜드는 비교도 안되는 거대한 라이벌들과의 대결을 계속해오면서 실제로 망할 뻔 했습니다.
(일반적으로 알고 계시는 상황보다 90년대 중반의 볼랜드의 상황은 훨씬 더 최악이었습니다)

그리고 그렇게 볼랜드가 망해갔던 과정에는, 님께서 믿고 계시는 바와는 오히려 정반대로,
그런 사소한 성의를 알아주지 않는 개발자들의 '배신'이 가장 큰 원인이었습니다.
윈도우 세상이 되어버린 것이 확실해진 95년 전후에, 거의 차이점이 없었던 볼랜드 C++과
비주얼C++ 사이에서 개발자들은 오랫동안 사용해왔던 볼랜드C++을 버리고 절대 다수가 비주얼C++로
돌아서버렸습니다. 왜냐고 물을 것도 없습니다. 윈도우를 만드는 회사의 개발툴이 더 낫지 않겠느냐..
라는 막연한 기대감으로요. 그리고 최소한 제 개인적으로는 비주얼C++보다 볼랜드C++이 조금 정도는
더 우수했습니다. (전 비주얼C++의 전 버전인 마이크로소프트 C 4.0부터 터보C와 함께 개발에
사용해본 몇 안되는 사람들중 하나입니다.)

기반 프로그래머라는 점에 자부심을 느끼시지요. 저도 마찬가지입니다.
하지만 MS가 수년내로 현재의 윈도우 플랫폼을 완전히 버릴 것이 확실해지고 있는 지금 상황에,
기존에 알고 있는 '기반 프로그래밍' 지식의 상당 부분은 휴지조각이 되어버립니다.

도스시절에 수십만줄의 코드로 된 아이콘 에디터를 만들었던 적이 있습니다.
지금은 그 소스조차도 잃어버려 정확하게는 기억이 안납니다만, 제 기억이 정확하다면 40만줄이 조금
넘었던 것 같습니다. 아이콘 에디터 하나에 왜 그렇게 많은 코드가 필요한지 이해가 안되실 수도
있겠지만, 당시에 흥미삼아 갖고놀고 있었던 윈도우 3.1의 UI를 똑같이 구현하느라 그랬습니다.
풀다운메뉴, 다단계 윈도우(이런 용어가 필요했던 때가 있었습니다), 여러가지 종류의 버튼,
스크롤바를 가진 리스트박스, 그딴 걸 만드는 데 수십만줄 대부분이 들어갔습니다.
그리고 장난감으로밖에 생각하지 않했던 윈도우가 도스를 완전히 밀어내면서, 라이브러리로까지
구축해놨던 그 코드들은 전부 휴지가 되었더랬습니다.

구체적으로는 아직 살펴보지 못했습니다만, 액티브X와 같은, 현재로서는 '기반'이라고 여겨지는
기술도 닷넷에서는 명맥 정도만 유지할 뿐 기능도 줄어들고 의미도 많이 쇄퇴된 것으로 들었습니다.

당연하지만 이런 경력 개발자를 바보 만드는 변화들은 볼랜드가 만들고 있는 것이 아닙니다.
그리고 유독 볼랜드 툴을 사용하는 개발자가 더 그런 것이 아닙니다. 오히려 정반대이지요.
요즘 비베 프로그래머들, VC 개발자들 보면 정말 안됐다는 생각이 절로 듭니다.

볼랜드가 닷넷 버전을 만들면서 어떻게 하고 있는지 아십니까?
닷넷 프레임워크를 VCL과 CLX에 매칭시키고 있습니다.
닷넷 버전에서도 기존의 프로그래밍 방법을 그대로 쓸 수 있도록 하기 위해서지요.
제 생각에는, 이런 것이 개발툴 벤더가 개발자에게 보여줄 수 있는 진정한 '성의'라고 생각합니다.


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

글을 써놓고 보니 제법 감정이 실렸습니다. 님의 글을 보다보니 답답한 생각이 들어서입니다.

아마도... 포럼에 오시는 대부분들이 이렇게 생각하실 겁니다.
제가 볼랜드툴들을 개인적으로 좋아하기 때문에 사이트를 게속 운영하고 있다.. 정도로요.
어느정도는 맞습니다. 초기에 한 1년 정도는 그런 맘으로 운영했었습니다.
하지만 단지 그것 때문이었다면 몇차례 있었던 힘든 시기에 사이트 운영을 그만뒀을 겁니다.

저는 이 사이트를 통해 개발자분들이 개발자로서 보다 먼 시각과 의식을 갖게 되기를 바랍니다.
당장 필요하니까 이런 도구를 사용하고 그 이상의 복잡한 생각은 필요없다라고 생각해버린다면,
개발자가 스스로를 또 하나의 도구로 전락시키는 그야말로 바보꼴입니다.

MS에게 개발툴 장사는 결코 남는 장사가 아닐텐데도 지속적으로 점점 더 많은 예산으로 개발자들을
붙잡아놓으려고 하는 이유가 뭐겠습니까. 또 MS가 닷넷 플랫폼을 내놓기 훨씬 전부터 막대한 예산으로
개발툴 시장부터 파고드는 이유가 뭐라고 생각하십니까.
간단합니다. IT 업계의 흐름의 모든 것은 개발자들의 선택에 따라 결정되기 때문이기 때문입니다.

어차피 영리를 추구하는 업체들인데 다 똑같지 않느냐는 자조적인 말엔 절대 동의할 수 없습니다.
개발자가 선택한 기업의 영리추구가 그 자체로 솔직하냐 아니면 딴 꿍꿍이가 있냐의 차이는 개발자들
스스로의 미래를 바꿔놓습니다.

그런 이유로, 설혹 볼랜드라고 하더라도 지금의 MS가 보여주는 것처럼 개발자들을 고객으로 대하기보단
마케팅 도구로 생각하게 된다면.. 제 시간을 할애해가며 이 사이트를 계속 운영하지는 않을 겁니다.
(안티볼랜드 사이트를 만들지도...?)

그리고 그런 이유로, 저는 볼랜드의 개발툴을 MS의 개발들과 비교하며 우열을 따지는 것 자체가 기분이
썩 좋지 않습니다.
그 차이는, 내가 쓰고 있는 화장지가 내 돈을 주고 산 것이냐, 아니면 판촉물로 얻은 것이냐의 차이보단
훨씬 더 심각한 결과를 낳으니까요.


한마디 더 덧붙인다면...
위에서 제가 부연을 달았던 대로, 빌더가 VC보다 꽤 버그가 있기는 하지만, 님께서 느끼시는 만큼
실제로 빌더가 버그투성이는 아니기에 기분이 좋지 않군요. (VC가 아닌 다른 툴과 비교할 순 없겠지요?)
그리고 불만을 토로하셨던 항목들 중 몇가지는, 상식의 선을 좀 넘어설 정도로 개인적인 취향의 평가이기에
더욱 그렇구요.