|
Hi!
I use this code to create the image list:
HIMAGELIST hImageList = ImageList_Create(16,16,ILC_MASK | ILC_COLOR32, 0, 1);
Then, in the code, I get hImageList and I want to get the flags (ILC_MASK | ILC_COLOR32)?
How must I do ?
Thanks you very much for your help
|
|
|
|
|
Here is the complete list of ImageList Functions[^]. ImageList_GetImageInfo will get you info about the image.
Yusuf
|
|
|
|
|
You cannot use ImageList_GetImageInfo to get the flags set during the creation of an imagelist.
I've already tried it, but no useful info can be retrieved in the structure IMAGEINFO
|
|
|
|
|
the command line of linker in project-property contains:kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
however it doesn't contain "boost_regex-vc80-mt-1_37.lib" which I used to use boost_regex-vc80-mt-1_37.dll and the latter one contains regex_search() function and so on. And I find I can use regex_search,smatch in My Application soomthly. All I do in my source code is including Two head files. I am wondering how does the complier locate "boost_regex-vc80-mt-1_37.lib"? I know there is only symbols(variable names,function names, etc)in .lib, even the complier gain the .lib, how the linker gain the corespondent .dll's name.
Can somebody tell me?
Thanks a lot.
modified on Friday, March 6, 2009 3:08 PM
|
|
|
|
|
JackPuppy wrote: smatch in My Application soomthly
I have no idea what that means
JackPuppy wrote: how the linker gain the corespondent .dll's name.
Perhaps they used this[^]?
|
|
|
|
|
In the linker option, you need to give the path of your boost lib.
Open your project properties dialog,
Config&properties->Linker->General Options->AddtitionalLibrarayDirectories[
Then in Input option,
Likner->Input->AdditionalDependencies[
Alternatively, In your code you can use
#pragma comment(lib,"Absolute_path_to_your_lib")
JackPuppy wrote: I know there is only symbols(variable names,function names, etc)in .lib, even the complier gain the .lib, how the linker gain the corespondent .dll's name.
Good question, but unfortunately the lib doesn't tell you about location details of your DLL. The lib just contains the exported symbols of the dll. It just talks about it. So when compiling you don't need the dll. Just a lib reference is enough. But at run time, you need to keep your dll along with your .exe or in system folders.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
thanks pal!
however I didn't "Likner->Input->AdditionalDependencies[// Here specify your boos lib] //Also you can give absolute paths here", neither "#pragma comment(lib,"Absolute_path_to_your_lib".
But I can use regex_search(), and why? it's confusing?(I did include the lib's directory in project property dialog).
Further the lib seems to contain at least the name of the dll, however see this lib codes I have dumpbin from a lib:
Microsoft (R) COFF/PE Dumper Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file E:Visual Studio 2005\Projects\DLLexperiment\debug\dllshiyan.lib
File Type: LIBRARY
Archive member name at 8: /
49B21595 time/date Sat Mar 07 14:35:01 2009
uid
gid
0 mode
7A size
correct header end
5 public symbols
17E __IMPORT_DESCRIPTOR_dllshiyan
3B0 __NULL_IMPORT_DESCRIPTOR
4EA dllshiyan_NULL_THUNK_DATA
642 __imp__add
642 _add
Archive member name at BE: /
49B21595 time/date Sat Mar 07 14:35:01 2009
uid
gid
0 mode
84 size
correct header end
4 offsets
1 17E
2 3B0
3 4EA
4 642
5 public symbols
1 __IMPORT_DESCRIPTOR_dllshiyan
2 __NULL_IMPORT_DESCRIPTOR
4 __imp__add
4 _add
3 dllshiyan_NULL_THUNK_DATA
Archive member name at 17E: dllshiyan.dll/
49B21595 time/date Sat Mar 07 14:35:01 2009
uid
gid
0 mode
1F6 size
correct header end
FILE HEADER VALUES
14C machine (x86)
3 number of sections
49B21595 time date stamp Sat Mar 07 14:35:01 2009
110 file pointer to symbol table
8 number of symbols
0 size of optional header
100 characteristics
32 bit word machine
SECTION HEADER #1
.debug$S name
0 physical address
0 virtual address
44 size of raw data
8C file pointer to raw data (0000008C to 000000CF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42100040 flags
Initialized Data
Discardable
1 byte align
Read Only
SECTION HEADER #2
.idata$2 name
0 physical address
0 virtual address
14 size of raw data
D0 file pointer to raw data (000000D0 to 000000E3)
E4 file pointer to relocation table
0 file pointer to line numbers
3 number of relocations
0 number of line numbers
C0300040 flags
Initialized Data
4 byte align
Read Write
RELOCATIONS #2
Symbol Symbol
Offset Type Applied To Index Name
-------- ---------------- ----------------- -------- ------
0000000C DIR32NB 00000000 3 .idata$6
00000000 DIR32NB 00000000 4 .idata$4
00000010 DIR32NB 00000000 5 .idata$5
SECTION HEADER #3
.idata$6 name
0 physical address
0 virtual address
E size of raw data
102 file pointer to raw data (00000102 to 0000010F)
E4 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0200040 flags
Initialized Data
2 byte align
Read Write
COFF SYMBOL TABLE
000 007BC627 ABS notype Static | @comp.id
001 00000000 SECT2 notype External | __IMPORT_DESCRIPTOR_dllshiyan
002 C0000040 SECT2 notype Section | .idata$2
003 00000000 SECT3 notype Static | .idata$6
004 C0000040 UNDEF notype Section | .idata$4
005 C0000040 UNDEF notype Section | .idata$5
006 00000000 UNDEF notype External | __NULL_IMPORT_DESCRIPTOR
007 00000000 UNDEF notype External | dllshiyan_NULL_THUNK_DATA
String Table Size = 0x56 bytes
Archive member name at 3B0: dllshiyan.dll/
49B21595 time/date Sat Mar 07 14:35:01 2009
uid
gid
0 mode
FD size
correct header end
FILE HEADER VALUES
14C machine (x86)
2 number of sections
49B21595 time date stamp Sat Mar 07 14:35:01 2009
BC file pointer to symbol table
2 number of symbols
0 size of optional header
100 characteristics
32 bit word machine
SECTION HEADER #1
.debug$S name
0 physical address
0 virtual address
44 size of raw data
64 file pointer to raw data (00000064 to 000000A7)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42100040 flags
Initialized Data
Discardable
1 byte align
Read Only
SECTION HEADER #2
.idata$3 name
0 physical address
0 virtual address
14 size of raw data
A8 file pointer to raw data (000000A8 to 000000BB)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0300040 flags
Initialized Data
4 byte align
Read Write
COFF SYMBOL TABLE
000 007BC627 ABS notype Static | @comp.id
001 00000000 SECT2 notype External | __NULL_IMPORT_DESCRIPTOR
String Table Size = 0x1D bytes
Archive member name at 4EA: dllshiyan.dll/
49B21595 time/date Sat Mar 07 14:35:01 2009
uid
gid
0 mode
11B size
correct header end
FILE HEADER VALUES
14C machine (x86)
3 number of sections
49B21595 time date stamp Sat Mar 07 14:35:01 2009
D8 file pointer to symbol table
2 number of symbols
0 size of optional header
100 characteristics
32 bit word machine
SECTION HEADER #1
.debug$S name
0 physical address
0 virtual address
44 size of raw data
8C file pointer to raw data (0000008C to 000000CF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42100040 flags
Initialized Data
Discardable
1 byte align
Read Only
SECTION HEADER #2
.idata$5 name
0 physical address
0 virtual address
4 size of raw data
D0 file pointer to raw data (000000D0 to 000000D3)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0300040 flags
Initialized Data
4 byte align
Read Write
SECTION HEADER #3
.idata$4 name
0 physical address
0 virtual address
4 size of raw data
D4 file pointer to raw data (000000D4 to 000000D7)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0300040 flags
Initialized Data
4 byte align
Read Write
COFF SYMBOL TABLE
000 007BC627 ABS notype Static | @comp.id
001 00000000 SECT2 notype External | dllshiyan_NULL_THUNK_DATA
String Table Size = 0x1F bytes
Archive member name at 642: dllshiyan.dll/
49B21595 time/date Sat Mar 07 14:35:01 2009
uid
gid
0 mode
27 size
correct header end
Version : 0
Machine : 14C (x86)
TimeDateStamp: 49B21595 Sat Mar 07 14:35:01 2009
SizeOfData : 00000013
DLL name : dllshiyan.dll
Symbol name : _add
Type : code
Name type : no prefix
Hint : 0
Name : add
Exports
ordinal name
_add
Dump of file
DUMPBIN : fatal error LNK1181: 无法打开输入文件""
|
|
|
|
|
there isn't(or I couldn't find it out)plus,this is really very confused reading, can you give me some acrtiles on what each sentence in this lib mean? thanks!
|
|
|
|
|
This[^] may help you. But I don't understand, why do you need to check them. You may want to DUMPBIN the contents of the DLL rather?
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
Hi All,
I have implemented a simple application, the WndProc method handle all messages, but when I debug the application I could see only numbers,
How can i know which message is associted with that perticular number?
more precisely I want know which number(message) WndProc handles when I minimize the application?
|
|
|
|
|
WM_SIZE & SIZE_MINIMIZED.
winuser.h
If you want to know all the definitions, just right click on any of the windows Constant. like WM_SIZE, then go to definition. You'll land up in the junkyard of windows definitions WinUser.h. But it'll be in Hex as you can see.So don't search for the exact number that you get in your WndProc.
Sorry I'm editing the text for the zillionth time.- You should check for SIZE_MINIMIZED in wParam of the message.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
modified on Friday, March 6, 2009 12:59 PM
|
|
|
|
|
I would like to do the click and Hold on the mouse, I would like to have this so I can move a gauge on a graph as long as the mouse click is down. I got some feedback from this forum to use OnMouseMove, but wouldn't this only work if you actually move the mouse..I want it to wok even if I left click and hold without actually moving the mouse... Any ideas of how I can do this?
Thanks
sft
|
|
|
|
|
Set a flag in OnLButtonDown() and move your gauge in the graph while flag is true (until OnLButtonUp(), where you reset the flag).
Hope that helps,
Jonnie
|
|
|
|
|
Thanks for the response: I tried something like this, but seems to get stuck in a loop and never move the gauge:
void CGraph::OnLButtonDown(flags,point){
m_Flag = 1;
while(m_Flag)
{
}
}
void CGraph::OnRButtonDown(flags,point){
m_Flag = 0;
}
sft
|
|
|
|
|
In OnLButtonDown, set a flag as someone else already suggested and use SetCapture[^] (Or CWnd::SetCapture) to capture the mouse input. Then in your WM_MOUSEMOVE handler, if the flag is set, perform the drag operation or whatever you need to do. In OnLButtonUp, clear the flag and use ReleaseCapture[^] to let the mouse go. Also, make a handler for WM_CAPTURECHANGED[^] and if it indicates that your window is loosing the capture, check the flag and if it is set, you know that something happened that took the mouse capture from your window while there was a drag operation in progress (for example another window was popped up) and clear the flag and do whatever else needs to do.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Thanks - I did something close to what you suggested in concept and it worked fine.
Thanks
sft
|
|
|
|
|
Software2007 wrote: ...I want it to wok even if I left click and hold without actually moving the mouse...
If the mouse is supposed to move the gauge, how would the gauge move if the mouse wasn't? In other words, what is the gauge supposed to be doing if the mouse's button is clicked but the mouse is not moving?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
fifth Edition
in Chapter 19, there is one note:
Note: It is important to realize that a single address space consists of one executable module and several DLL modules. Some of these modules can link to a static version of the C/ C++ run-time library, some of these modules might link to a DLL version of the C/C++ run-time library, and some of these modules (if not written in C/C++) might not require the C/ C++ run-time library at all. Many developers make a common mistake because they forget that several C/C++ run-time libraries can be present in a single address space. Examine the following code:
VOID EXEFunc() {
PVOID pv = DLLFunc();
// Access the storage pointed to by pv...
// Assumes that pv is in EXE's C/C++ run-time heap
free(pv);
}
PVOID DLLFunc() {
// Allocate block from DLL's C/C++ run-time heap
return(malloc(100));
}
So, what do you think? Does the preceding code work correctly? Is the block allocated by the DLL's function freed by the EXE's function? The answer is: maybe. The code shown does not give you enough information. If both the EXE and the DLL link to the DLL C/C++ run-time library, the code works just fine. However, if one or both of the modules link to the static C/C++ run-time library, the call to free fails. I have seen developers write code similar to this too many times, and it has burned them all.
===========================================================================
At first one thing the starup() function do is to initialize a heap used by malloc and free and low-level IO manipulation use in CRT, so when there is two copies CRT liberary in one process adress and there will be two heaps for two groups of malloc and free, and that one block memory grabed by malloc can only be freed by the very free() function in the same copy.
but what free() is?
in fact free()'s source code is like this:
void free(void *ptr)
{
struct mem_control_block *free;
free = ptr - sizeof(struct mem_control_block);
free->is_available = 1;
return;
}
every malloc()function return pointer to a block,however there are some bytes ahead the block conserved for system information, and this information is stored in a struct mem_control_block, so indeed the pointer malloc()function returned points to the byte after the mem_control_block.
struct mem_control_block {
int is_available; //a flag that specify whether this block can be used by any other application
int size; //the size of the block
};
finnally, it seems no error in these code:
VOID EXEFunc() {
PVOID pv = DLLFunc();
// Access the storage pointed to by pv...
// Assumes that pv is in EXE's C/C++ run-time heap
free(pv);
}
PVOID DLLFunc() {
// Allocate block from DLL's C/C++ run-time heap
return(malloc(100));
}
if the system doesn't allow a free() to free a block in heap of another copy of CRT, then how the system is able to forbid?????
Thanks for your help.
I'm struggle reading win via c/c++
Jack
modified on Friday, March 6, 2009 11:13 AM
|
|
|
|
|
Thanks for sharing the information! lol
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
Can somebody tell me what's wrong with the code?
I see no error in it, especially after i found out what free()is.
|
|
|
|
|
Send e-mail to get answer.
|
|
|
|
|
Hey man, thanks a lot, that's what I want.
But it is still lacking of more explanation in deep, any way, it's enough.
Any more clear in-depth explanation will be appreciated!
Jack
|
|
|
|
|
Send e-mail to get answer.
modified on Tuesday, March 10, 2009 10:16 AM
|
|
|
|
|
do you know what "ertain types of objects" are created using CRT heap? and why is a necessary?
Further, it seems unecessary to allocate a heap per CRT copy, in stead of let all CRTs use exe. heap, which is what heap meant to be.
So if the CRT heap exists, it must have a good reason. The reason lies on the data stored in the heap, what data and why stored there?
|
|
|
|
|
"d now there matching everything as if the object was created at the local heap" this is odd, then there is no need to allocate a heap for CRT.
is all this back-compatible consideration? the original CRT developers use this mechanism for some specific reason that is rarely used today but for compatible's sake Microsoft still maintain this feature?
|
|
|
|