검색결과 리스트
vc++에 해당되는 글 13건
- 2013.08.07 [VC++] dependency walker
- 2013.06.13 [VC++] Device Info
- 2013.06.12 [VC++] Getting the PropertyData of ManagementObject in C++
- 2013.05.31 [VC++] 콘솔 프로세스의 리디렉션된 표준핸들이 생성되는 방법
- 2013.05.30 [VC++] Detecting Hardware Insertion and/or Removal
- 2013.05.21 [VC++] IOCP 프로그래밍 1
- 2013.05.01 [VC++] Visual Studio Predefine Macro
- 2013.03.14 [VC++] Design Specifications and Guidelines - Visual Design
- 2013.03.08 [VC++] 모듈 정의 파일(.def)을 이용해서 EXPORTS 시키기
- 2011.08.05 [VC++] visual studio 2008 Excel Automation "\excel.tlh(1219) : error C2371: 'FontPtr' : redefinition; different basic types"
- 2011.02.16 Predefines Macros
- 2011.01.20 VC++에서 ADO를 사용하는 방법
- 2009.02.03 CoInitialize(), CoUninitialize() 호출시 주의사항
글
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[C++] Crypto++ (0) | 2014.07.25 |
---|---|
[WinDBG] 사용시 참고할만한 사이트 (0) | 2014.01.03 |
[VC++] Device Info (0) | 2013.06.13 |
[VC++] Getting the PropertyData of ManagementObject in C++ (0) | 2013.06.12 |
[VC++] 윈도우 OS Bit 판별하기 (0) | 2013.05.31 |
트랙백
댓글
글
장치관리자 Device Tree: http://www.codeproject.com/Articles/6597/CDeviceTree
Enumerate Properties: http://www.codeproject.com/Articles/6866/Enumerate-Properties-of-an-Installed-Device
장치 열거하기 (한글) : http://blog.naver.com/cra2yboy?Redirect=Log&logNo=90165203152
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[WinDBG] 사용시 참고할만한 사이트 (0) | 2014.01.03 |
---|---|
[VC++] dependency walker (0) | 2013.08.07 |
[VC++] Getting the PropertyData of ManagementObject in C++ (0) | 2013.06.12 |
[VC++] 윈도우 OS Bit 판별하기 (0) | 2013.05.31 |
[VC++] 콘솔 프로세스의 리디렉션된 표준핸들이 생성되는 방법 (0) | 2013.05.31 |
트랙백
댓글
글
링크 : http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/1ba183a5-71bb-4601-beb6-73ba20b087cd/
IWbemService Interface : http://msdn.microsoft.com/en-us/library/aa392093(v=vs.85).aspx
MSDN 예제 : http://msdn.microsoft.com/en-us/library/aa390425(v=VS.85).aspx
Query : http://msdn.microsoft.com/en-us/library/aa392902(v=vs.85).aspx
WMI 데이터판독기 작업 : http://sqlmvp.kr/140163038957
WMI를 이용한 프로세스 감시 : http://blog.naver.com/adsloader?Redirect=Log&logNo=50142012166
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[VC++] dependency walker (0) | 2013.08.07 |
---|---|
[VC++] Device Info (0) | 2013.06.13 |
[VC++] 윈도우 OS Bit 판별하기 (0) | 2013.05.31 |
[VC++] 콘솔 프로세스의 리디렉션된 표준핸들이 생성되는 방법 (0) | 2013.05.31 |
[VC++] DevCon 사용법 (0) | 2013.05.31 |
트랙백
댓글
글
링크 : http://support.microsoft.com/kb/190351/ko
한마디로 자식 프로세스를 생성해서 Input, Output으로 주고 받는 방법이다.
참고 : http://www.tipssoft.com/bulletin/board.php?bo_table=update&wr_id=941
팁스소프트의 좋은 예제
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[VC++] Getting the PropertyData of ManagementObject in C++ (0) | 2013.06.12 |
---|---|
[VC++] 윈도우 OS Bit 판별하기 (0) | 2013.05.31 |
[VC++] DevCon 사용법 (0) | 2013.05.31 |
[MFC] Dialog 베이스로 시작시 숨기기 (0) | 2013.05.31 |
[VC++] Detecting Hardware Insertion and/or Removal (0) | 2013.05.30 |
트랙백
댓글
글
링크 : http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-or-Removal
링크 : http://msdn.microsoft.com/en-us/library/windows/desktop/aa363432(v=vs.85).aspx
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[VC++] DevCon 사용법 (0) | 2013.05.31 |
---|---|
[MFC] Dialog 베이스로 시작시 숨기기 (0) | 2013.05.31 |
[ATL] ATL Com Programming (0) | 2013.05.24 |
[COM] Com Event Handling (0) | 2013.05.24 |
[VC++] IOCP 프로그래밍 (1) | 2013.05.21 |
트랙백
댓글
글
참고소스 : http://blog.daum.net/aswip/2580198
출처 : http://blog.naver.com/sonmg?Redirect=Log&logNo=20000462755
IOCP- 윈속 프로그래밍 | 2002년 08월 21일 | 03시 05분 |
|
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[ATL] ATL Com Programming (0) | 2013.05.24 |
---|---|
[COM] Com Event Handling (0) | 2013.05.24 |
[VC++] Visual Studio Predefine Macro (0) | 2013.05.01 |
[VC++] Tray Icon Animation (0) | 2013.04.26 |
[VC++] Design Specifications and Guidelines - Visual Design (0) | 2013.03.14 |
트랙백
댓글
글
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[COM] Com Event Handling (0) | 2013.05.24 |
---|---|
[VC++] IOCP 프로그래밍 (1) | 2013.05.21 |
[VC++] Tray Icon Animation (0) | 2013.04.26 |
[VC++] Design Specifications and Guidelines - Visual Design (0) | 2013.03.14 |
[VC++] 모듈 정의 파일(.def)을 이용해서 EXPORTS 시키기 (0) | 2013.03.08 |
트랙백
댓글
글
링크 : http://msdn.microsoft.com/en-us/library/ms997619.aspx
Design Specifications and Guidelines - Visual Design
Layout
Size, spacing, and placement of information are critical in creating a visually consistent and predictable environment. Visual structure is also important for communicating the purpose of the elements displayed in a window. In general, follow the layout conventions for how information is read. In Western countries, this means left-to-right, top-to-bottom, with the most important information located in the upper left corner.
The system defines the size and location of user interface elements in a window based on dialog units (DLUs), not pixels. A dialog unit is the device-independent measure to use for layout. One horizontal dialog unit is equal to one-fourth of the average character width for the current system font. One vertical dialog unit is equal to one-eighth of an average character height for the current system font. The default height for most single-line controls is 14 DLUs. Be careful if you use a pixel-based drawing program, because it may not provide an accurate representation when you translate your design into dialog units. If you do use a pixel-based drawing tool, you may want to take screen snapshots from a development tool that supports dialog units and use those images.
More Information
Your application can retrieve the number of pixels per base unit for the current display using the GetDialogBaseUnits function. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site.
Size
The following table lists the typical height and width of common dialog box controls.
Size of Common Dialog Box Controls | ||
---|---|---|
Control | Height (DLUs) | Width (DLUs) |
Dialog boxes and property sheets | 263 max. (for 640 x 480 screen resolution) 218 215 188 | 263 max. (for 640 x 480 screen resolution) 252 227 212 |
(For property sheets, heights include 25 DLUs for property sheet button bars.) | ||
Command buttons | 14 | 50 |
Check boxes | 10 | As wide as needed |
Drop-down combo box and drop-down list | 10 | Size to match other drop-down combo boxes and text boxes |
Option buttons | 10 | As wide as needed |
Text boxes | 14 | Size to match other drop-down combo boxes and text boxes |
Text labels | 8 per line of text | As wide as needed |
Other screen text | 8 per line of text | As wide as needed |
More Information
To support localization, you should make controls wider than just enough to display the labels. For more information, see Chapter 15, "Special Design Considerations."
Toolbars and their buttons use pixels instead of dialog units for their measurement. The recommended sizes are shown in the following table.
Size of Toolbars and Toolbar Buttons | ||
---|---|---|
Control | Height (pixels) | Width (pixels) |
Toolbars in small button mode | 23 | Width of toolbar area or window |
Toolbars in large button mode | 28 | Width of toolbar area or window |
Small toolbar buttons | 21 | Depends on content; 22 if the button includes only an image |
Large toolbar buttons | 26 | Depends on content; 28 if the button includes only an image |
When you cannot reasonably apply the size guidelines for secondary windows, try to maintain a width within a task. This can provide a smooth transition, making it easier for a user to focus on the task. Also, always check to make sure that the window will fit in the minimum screen resolution set by your application's users. Typically, this means using a 640 x 480 resolution screen to ensure that it fits completely. You must also take into account the possible space taken up by the task bar and other desktop toolbars.
Make buttons a consistent length for readability. However, if maintaining this consistency greatly expands the space required for a set of buttons, it may be reasonable to have one button larger than the rest.
Similarly, if you use tabs, try to maintain a consistent width for all tabs in the same window (and in the same dimension). However, if a particular tab's label makes this unworkable, size it larger and maintain a smaller, consistent size for the other tabs. If a tab's label contains variable text, you can size the tab to fit the label, up to some reasonable maximum, after which you truncate the text and add an ellipsis.
Try to maintain a consistent width between text boxes and the list boxes they appear near, using only one or two different widths per group or window. If you localize your application, you should extend text, option button labels, and check box labels to be as wide as the group or window, where possible. This will reduce the work necessary to localize your interface.
Spacing and Positioning
Maintain a consistent margin from the edge of the window seven dialog units is recommended. Use spacing between groups within the window, as shown in Figure 14.27.
Figure 14.27 Recommended layout and spacing of controls and text (click to enlarge image)
The following table lists the typical items found in an interface and the recommended spacing between them.
Spacing Between Interface Items | ||
---|---|---|
Interface items | Use this spacing (DLUs) | |
Dialog box margins | 7 on all sides | |
Between paragraphs of text | 7 | |
Between text labels and their associated controls (for example, text boxes and list boxes) | 3 | |
Between related controls | 4 | |
Between unrelated controls | 7 | |
First control in a group box | 11 down from the top of the group box; align vertically to the group box title | |
Between controls in a group box | 4; align vertically to the group box title | |
Between horizontally or vertically arranged buttons | 4; align vertically to the group box title | |
From the left edge of a group box | 9; if the group box is left-aligned, controls are 16 from the left edge of the dialog box or property page | |
Last control in a group box | 7 above the bottom of the group box | |
Smallest space between controls | 2 | |
Text label beside a button | 3 down from the top of the button | |
Check box, list box, or option button beside a button | 2 down from the top of the button | |
Toolbars and their buttons use pixels instead of DLUs. The following table provides spacing for toolbar buttons.
Spacing for toolbar buttons | ||
---|---|---|
Button Size | Spacing | |
Small (16 x 16 pixel image) toolbar buttons | 3 pixels between a button and its text label 2 pixels above the toolbar image 3 pixels below the toolbar image | |
Large (20 x 20 pixel image) toolbar buttons | 3 pixels between a button and its text label 2 pixels above the toolbar image 2 pixels below the toolbar image | |
In general, for controls that do not contain their own labels, place the label to the left or above the related control. This makes it easier for users to associate the label with the corresponding control.
When a text box is the first item in the group box, use a smaller measurement so the visual spacing above and to the right looks equal. In cases where there are controls below a group box, align the controls to the edge of the group box above and use seven DLUs between the bottom edge of the group box and the control (or text), as shown in Figure 14.28.
Figure 14.28 Example of group box spacing (click to enlarge image)
Position controls in a toolbar so that there is at least a window's border width from the edges of the toolbar, as shown below.
Use at least 4 DLUs between controls, except for between a set of related toolbar buttons. There should be no space between adjacent toolbar buttons, such as a set of related option buttons.
For wizard design, Figure 14.29 shows suggested positioning and spacing.
Figure 14.29 Positioning and spacing in a wizard (click to enlarge image)
Grouping
Group related components you can use group box controls, separator lines, or spacing. Although you can also use color to visually group objects, it is not a common convention and could result in undesirable effects if the user changes color schemes.
A group box provides a strong visual element for related items. However, avoid using a group box when you have only one set of related items or where the group box may take too much space or add visual clutter rather than structure. Instead, consider using separators to group related items. Property sheets for files and folders are a good illustration of the use of separators rather than group boxes.
Stack the main command buttons in a secondary window in the upper right corner or in a row along the bottom, as shown in Figure 14.30. If there is a default button, it is typically the first button in the set. Place OK and Cancel buttons next to each other. If there is no OKbutton but there are command buttons that initiate action, place the Cancel button at the end of the buttons but before a Help button. If a particular command button applies only to a particular field, group it with that field.
More Information
For more information about button placement in secondary windows, see Chapter 9, "Secondary Windows."
Figure 14.30 Layout of buttons (click to enlarge image)
Group controls so that their location helps users understand the associated context or scope. For tabbed pages, follow these guidelines:
- When command buttons and other controls apply only to that page, place them within the border of the tabbed page.
- When command buttons and other controls apply to the entire window, place them outside the tabbed page.
Alignment
When information is positioned vertically, align fields by their left edges (in western countries). This usually makes it easier for the user to scan the information. Text labels are usually left-aligned and placed above or to the left of the areas to which they apply. When placing text labels to the left of text box controls, align the top of the text with text displayed in the text box.
In group boxes, controls should be left-aligned with the text label of the group. However, command buttons in the group should be right-aligned.
Align command buttons in most secondary windows at the top right or right-align them with the bottom. The exception is for message boxes, where command buttons should be centered. In toolbar arrangements, buttons and other controls are typically left- or top-aligned, depending on the layout of the area.
Required and Optional Input
For input form design, you may want to require certain input fields or controls and make others optional. To help users distinguish required input from optional input, provide some form of visual differentiation. The best way to do this is to separate the two sets of input into separate windows, panes, or groups and label the fields accordingly. However, this may not always work with the type of information you are presenting. The next best way is to label the individual fields with the words "required" or "optional" in parentheses. You can also use fonts, symbols, or graphics; however, such conventions require the user to learn the convention in order to use the application effectively. In scenarios where you cannot rely on training the user, use a more obvious form of identification. Do not use color unless you are using some other form of feedback as well. Color may attract the user's attention, but the perception of color can vary. Therefore, do not rely on it as the only means of identification.
Preview and Sample Boxes
In some situations, you may want to provide an area for a visual example of changes a user is making to an item, as shown in Figure 14.31.
Figure 14.31 Preview or sample box (click to enlarge image)
A sample is a representation of what might show up on screen, but it does not show the actual data that the user is working on. In contrast, a preview shows the user's actual data.
Include text, graphics, or both in your preview or sample boxes. The preview can be illustrative and interactive. If the preview is interactive, include instructions or some visual cue to let the user know that it is interactive.
Include a label for your preview or sample box, and keep the wording for the label brief. A one- or two-word label (often Preview or Sample) is usually sufficient unless the user needs to interact with the preview to update it. Use sentence-style capitalization for the label, but do not include ending punctuation unless the user can interact with the preview, in which case end the label with a colon.
Fundamentals of Designing User Interaction
Windows Interface Components
Design Specifications and Guidelines
Appendixes and References
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[VC++] Visual Studio Predefine Macro (0) | 2013.05.01 |
---|---|
[VC++] Tray Icon Animation (0) | 2013.04.26 |
[VC++] 모듈 정의 파일(.def)을 이용해서 EXPORTS 시키기 (0) | 2013.03.08 |
[C++] C++11 (0) | 2013.01.29 |
[COM] WebBrowser Customization (0) | 2012.12.29 |
트랙백
댓글
글
외부 프로그램과 연동하는 dll을 만들어야 했는데 .h, .lib를 같이 배포했기 때문에 __declspec을 사용했었습니다.
다른 방법으로는 모듈 정의 파일을 이용하는 방법도 있습니다.
프로젝트 속성 -> 구성속성 -> 링커 -> 입력 -> 모듈 정의 파일
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[VC++] Tray Icon Animation (0) | 2013.04.26 |
---|---|
[VC++] Design Specifications and Guidelines - Visual Design (0) | 2013.03.14 |
[C++] C++11 (0) | 2013.01.29 |
[COM] WebBrowser Customization (0) | 2012.12.29 |
[VC++] visual studio 2008 Excel Automation "\excel.tlh(1219) : error C2371: 'FontPtr' : redefinition; different basic types" (0) | 2011.08.05 |
트랙백
댓글
글
[VC++] visual studio 2008 Excel Automation "\excel.tlh(1219) : error C2371: 'FontPtr' : redefinition; different basic types"
설정
알수 없는 에러가 발생했다.
#해결1
http://www.ms-news.net/f3295/ms-office-type-library-problem-2533193.html
참조 : http://support.microsoft.com/kb/308292
http://support.microsoft.com/kb/311407/EN-US
#해결2
에러는 해결했는데 Warning이 발생한것도 있고 Typelib를 이용해서 클래스 만들어주는게 다 만들어주는것도 아니고해서
결국직접 typelib를 임포트 해서 스마트포인터를 사용해서 해결했다.
#import "C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\OFFICE11\\MOS.DLL" \ rename("RGB", "excelRGB") #import "C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VBA\\VBA6\\VBE6EXT.OLB" #import "C:\\Program Files (x86)\\Microsoft Office\\OFFICE11\\excel.exe" \ rename("DialogBox", "excelDialogBox") \ rename("RGB", "excelRGB") \ rename("CopyFile", "excelCopyFile") \ no_dual_interface using namespace Excel;
* office11은 MS Office 2003 버전이다.
* 32bit 버전이라면 'Program Files (x86)'이 아니라 'Program Files' 이다.
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[C++] C++11 (0) | 2013.01.29 |
---|---|
[COM] WebBrowser Customization (0) | 2012.12.29 |
[MFC] MFC에서 Token 분리 (0) | 2011.07.21 |
[MFC] CListCtrl 현재 행 선택하기 (0) | 2011.03.20 |
COM Automation 에서 옵션인자 설정 방법 (0) | 2011.03.03 |
트랙백
댓글
글
그중 __FILE__, __LINE__, __FUNCTION__은 디버깅시 유용합니다.
__FILE__ : 현재 소스의 파일 경로 문자열을 리턴
__LINE__ : 소스 파일의 라인번호 숫자를 리턴
__FUNCTION__ : 현재 위치의 함수 이름 문자열을 리턴
참고 ( http://msdn.microsoft.com/en-us/library/b0084kay(VS.71).aspx )
'C/C++ > VC++ / MFC' 카테고리의 다른 글
COM Automation 에서 옵션인자 설정 방법 (0) | 2011.03.03 |
---|---|
#pragma message (0) | 2011.02.25 |
[링크] 일정 시간이 흐른후 메세지 박스 종료하기 (0) | 2011.02.15 |
[MFC] Ansi -> Unicode 형변환 (0) | 2011.02.08 |
PathIsDirectory 유효한 폴더명인지 확인 할 수 있는 API (0) | 2011.01.24 |
트랙백
댓글
글
1. OLE DB SDK라이브러리를 이용하는 방법
2. #import를 이용하여 Type Library를 이용하는 방법
전 개인적으로 2번째 방법을 선호합니다.
그리고 Type Library를 import 하면 스마트 포인터를 사용할수 있기때문에 편리합니다.
#import를 할려면 msadoxx.tlb 파일이나 msadoxx.dll 파일이 필요합니다.
ado는 버전별로 있기때문에 본인에게 맞는 버전을 사용하면 됩니다.
import할 파일은 C:\Program Files\Common Files\System\ado\ 에 있습니다.
MFC를 이용해서 프로그래밍을 한다면 StdAfx.h에 선언해 주는게 편합니다.
StdAfx.h에 선언하지 않으면 사용하는 곳마다 계속 선언을 해줘야 합니다.
//StdAfx.h //... #import "C:\\Program Files\\Common Files\\System\\ado\\msado26.tlb" \ no_namespace rename("EOF", "adoEOF") //...
type library를 임포트 할려면 .tlb라는 파일이 필요한데 ado는 .dll에도 type library가 저장되어 있습니다.
따라서 .tlb, .dll 둘중에 아무거나 임포트 하시면 됩니다.
namespace를 사용하지 않게 옵션을 주어서 코딩시 편하게 할 수 있습니다.
간혹 이름 충돌이 발생할수 있는데 그럴때는 rename_namespace("새로운이름") 옵션으로 이름을 변경해
주시면 됩니다.
rename("EOF", "adoEOF")는 혹 다른곳에서 EOF를 사용함으로 해서 충돌나는 것을 방지해줍니다.
'C/C++ > VC++ / MFC' 카테고리의 다른 글
[MFC] 현재 프로그램의 Instance Handle을 구하는 API (0) | 2011.01.24 |
---|---|
WINDOWS API 폴더 선택 (0) | 2011.01.21 |
Visual Studio 2008 Release 모드에서 디버깅 하기 (0) | 2010.10.03 |
[WTL] Visual Studio 2008 WTL AppWizMobile 오류 해결 (0) | 2010.09.16 |
MFC 디버깅시 MS MFC 소스코드를 쫓아서 디버깅할때는 Static Library... (0) | 2010.09.03 |
트랙백
댓글
글
저는 ADO를 통해서 Oracle에 접근하기 위해서 사용했습니다.
단순한 생각으로 처음부터 DB에 연결해서 주구장창 하나로 사용하려고 했습니다.
그래서 다중접속 부분의 동시접속 문제는 CriticalSection을 이용했는데
알고 보니 이게 좋은 방법이 아니었습니다.
그래서 각 유저가 접속할때마다 DB를 Open하고 쿼리 날리고 DB를 Close 할려고 했는데
CreateInstance를 생성할때마다 스마트포인터가 NULL로 되더군요..
알고 봤더니 COM을 MFC에서 사용하기 위해서는
CoInitialize를 호출하는데 이건 스레드당 한개씩 오픈해야 한다는 것 입니다.
제가 다중접속을 위해서 별도의 스레드로 소켓을 이용한 프로그래밍을 했는데
각각 별도의 스레드에서 DB를 접속할려고 하니 안되는 거였습니다. ㅡㅡ;
결국 스레드당 접속을 한 결과 접속을 잘 해결되었습니다.
1. CoInitialize()와 CoUninitialize()는 꼭 짝으로 이뤄서 사용하자 :
C++이라면 클래스로 만들어서 생성자에서 CoInitialize()하고 소멸자에서 CoUninitialize()하면
좋겠죠
2. ADO 사용을 편하게 하기 위해서 스마트 포인터를 사용하는데... 스마트 포인터는 내부적으로
소멸자에서 Release()를 호출해 줍니다. 따라서 명시적으로 Release()를 호출하면은 안됩니다.
하나라도 정확하게 알고 사용하는거와
모르고 사용하는건 큰 차이가 있을을 다시 한번 느꼇습니다.
이거 배워야 할게 너무도 많네요... ^^
'OS > Windows' 카테고리의 다른 글
HMODULE과 HINSTANCE의 차이점 (0) | 2011.02.08 |
---|---|
Windows API만 사용해서 BN_CLICKED 메세지 발생시키기 (0) | 2009.08.12 |
Release에서 디버깅 하기 ... (0) | 2008.11.21 |
GetExitCodeThread 로 스레드의 상태를 알아보기 (0) | 2008.09.27 |
InternetSetOption의 Timeout 설정 버그 (0) | 2008.09.16 |
RECENT COMMENT