|
rrrado wrote: I've wrote before i've solved it by sending WM_CANCELMODE message
I've seen your post , after posting mine. And today, there seems to be problem with modifying post. So, it is there as it is. 
|
|
|
|
|
Hi,
I want to display a text with underline in my view class.
Can we do this in our coding?Any functions is there?
Ex: TEXT
I do not use CPoint to display there.
I am copying the text to somevariable and then i pass this to dll function and then it display in view window.
code:
strcpy(czTemp"TEXT");
Anu
|
|
|
|
|
hi,
check for CFont in MSDN.
//
CFont fntArial, fntBoldSwiss;
fntArial.CreateFont( 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, "Arial" );
fntBoldSwiss.CreateFont( rcClient.Height()/20, 0, 0, 0,
FW_BOLD, TRUE, FALSE, 0, ANSI_CHARSET,
OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY, DEFAULT_PITCH | FF_SWISS,
NULL );
Uday kiran
|
|
|
|
|
Your question doesn't really make sense. If you pass a char array to a dll that is in charge of the display of the string and if you cannot change it, then it is impossible. A char array doesn't contain any formating informations, it contains data only (so, only the letters of your string).
|
|
|
|
|
You can set fdwUnderline to true in CreateFont and if you use of CDC for write to screen use SelectObject
|
|
|
|
|
Hi
MessageBox(NULL, "Hello World", "Message Box Title -- Hello World", MB_OK);
Error:
error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char [12]' to 'LPCWSTR'
IDE:VS2005
I don't understand why it gives this error.
Can you please tell me what the problem is and how i can solve it.
Thanks
|
|
|
|
|
hi,
L"Hellow World"
in the MessageBox.
Uday kiran
|
|
|
|
|
The default project charset setting in VS2005 is using UNICODE, so the MessageBox maps to MessageBoxW, which takes unicode strings as its input.
You can 1. changing your project's setting from using UNICODE to MBCS 2. enclose each of the string appeared in your source files with _T(). Or you can do both.
The _T macro will map the string to wide char string constant if the project is set to use UNICODE, and will map the string to normal ANSI string constants if the project is set to use MBCS charset.
|
|
|
|
|
thanks for fast reply
but
for _T("Message Box Title -- Hello World")
error C3861: '_T': identifier not found
for L"Message Box Title -- Hello World"
same error C2664
|
|
|
|
|
sorry friends
L is ok.
It works.Thank you.
But _T macro can not find it says.
How can i tell compiler to see this macro.I opened only empty win. application.
Thanks again.
Edit/Delete Message
|
|
|
|
|
|
thanks friends
TEXT() is working; also for _T macro #include <tchar.h> is solve the problem.
|
|
|
|
|
sawerr wrote: But _T macro can not find it says.
What does this mean? _T() macro is defined in tchar.h; But again finally expands to L""
|
|
|
|
|
what type of project u r using?
|
|
|
|
|
hi all,
i am having doubt in Socket Programming, What is the need of select(...) Api in Socket. Please give me a neat explation of what the select(...) Api do in Socket and where we can apply this Api.
Also i want the Difference between Blocking and NonBlocking Sockets.
please help me out.
Uday kiran
|
|
|
|
|
uday kiran janaswamy wrote: need of select(...) Api in Socket.
If an application is using several sockets then the select() function may be used to find out which ones are active.
uday kiran janaswamy wrote: Also i want the Difference between Blocking and NonBlocking Sockets.
See here. You will get a lot of information relating to blocking and non-blocking sockets.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
hi all,
i want the difference of heap and stack in memory related area.
also when you populate the CDialog i am having doubt.
CDialog d; ---> First
d.DoModel();
CDialog *d = new CDialog; ---->Second
d->DoModel();
both First and Second will populate the Dialog but can i know what is the difference of the First and Second Memory Concept.
please let me know.
Uday kiran
|
|
|
|
|
uday kiran janaswamy wrote: difference of heap and stack in memory related area
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
uday kiran janaswamy wrote:
CDialog d; ---> First
d.DoModel();
Object is created on the stack. No chances for memory leak but the amount of memory on the stack is small and the store can get exhausted.
uday kiran janaswamy wrote: CDialog *d = new CDialog; ---->Second
d->DoModel();
Object is created on heap.
While allocating memory on the heap you are responsible for deallocating memory. Each byte of memory that's being assigned/used should be returned back to the heap after it's task is done or else there is a problem that is known as Memory Leak.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
Really? I always thought memory was memory!
Using the stack is generally faster than the heap, since you don't have the overhead of managing a pool of memory. Individual allocations of stack memory cannot be freed, since it's done on a 'frame' basis, and everything in the current frame is cleaned up (albeit sequentially).
In the snippet
CDialog d;
the object itself is stack-based, and will automatically have it's destructor called when the function returns (as the object will go out of scope).
In the snippet
CDialog* d = new CDialog;
the variable is stack-based, but the object itself is on the heap. When the function completes, the variable that refers to the object goes out of scope, but the object still exists, as you say. It will not have a destructor called automatically.
There is, AFAICR, nothing which forces primitives to live on the stack, and force objects to be allocated on the heap. Usually the developer decides, particularly in the situation of developing for Windows, where UI objects need to exist beyond the lifetime of a function.
Steve S
Developer for hire
|
|
|
|
|
hi steve,
i understand the concept of stack and heap i am very thankfull to you to give a nice example.
Uday kiran
|
|
|
|
|
Steve S wrote: I always thought memory was memory!
In a computer there is only one variable storage area, the main computer RAM. But, for the purpose of organization and performance, it is divided into several areas.
When you C/C++ program is started, memory is requested to the operating system to create the heap and the stack.
Both these memory areas use what we could call the heap (not the stack). They are accessed by dereferencing pointers, like in the code below:
struct S {
int x;
int y;
int z;
};
int main(void) {
S* var_s;
var_s=new S;
if (!var_s) return __LINE__;
var_s->y=20;
}
In this code, the structure S will have a total of 12 bytes (in Win32), because each integer takes 4 bytes. The new will return some relatively unpredictable address in memory, which is not that important. The only important value to check for is zero, which means the requested memory is not available (that's why the "if" statement is there).
When your program starts, another area of memory is allocated, the stack. This memory is just like any other, but it is considered must more volatile, and besides it is also used where to go to when functions terminate. The stack is considered to be memory like "remember this for a moment while I do something else, and then I will get back to this".
1) The address of the variable var_s is always known by using the stack pointer, which is a physical register of the processor.
2) The stack is very dense. Everything is packed together, and only the memory area after the stack pointer is free. Everything else from the start of the stack up to the stack pointer is densely occupied.
3) All the relative addresses of things stored in the stack are predictable. For example, while inside main, the return address could also be known, independently from where your program came from, by reading memory addresses 5000 to 5003 (4 bytes before the address of var_s). In reality, when main begins there is more stuff added to the stack which makes the var_s ocuppy addresses further from the main return address, but still it is possible to check all variables and function return addresses by navigating through the stack.
4) Although everything is accessible in the stack, by navigating in it, new things can be memorized only after previously memorized things. The stack can contain no holes, and that is the main diference to the heap. So, only the most recent things can be forgotten go release memory for new things. This means that you cannot forget the address o contents 5000 and used for storing other things, unless you forget about var_s first.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
You aren't telling me anything I didn't already know (I've programmed in 6502, Z80, MC68000 and 80x86 assembly language).
My point was that stack memory isn't physically faster per se than the heap, since it's all stored in the same stuff (although cache hits on the stack region are more likely to succeed).
Sure, a stack allocation is much faster, since you don't have to worry about maintaining coherence or multiple threads running parallel allocation/deallocation, and deallocation is likewise easier. That's why stack-based variables are/were referred to in Kernighan and Ritchie as 'auto' or 'automatic' variables. Space is automatically allocated and deallocated on request.
You do make the point, of course, that the stack isn't limitless, and a couple of questions I've seen posted on CP were resolved by changing to use dynamic rather than automatically allocated variables. However, I felt that the comment on speed was likely to confuse the OP, and lead them away from the facts...
Steve S
Developer for hire
|
|
|
|
|
Thanks for the information Steve. I got to know a few more things through this thread.
Thanks once again....
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
hi everyone,
I am doing the unicode version of the project. The function of DragQueryFile(API) work well,but in the version of unicode, it is different from the version fo ansi, when I use this windows API, first it should return the count of file I have dragged, and I can get the path of each file, but it is not this, in the uncode vesion the value it return is likely the length of the file path, and when I get the path, I doesn't return the path in whole, It return the first character of the path.
for example, in ansi the value returned is 1(the count of file),"c:\test\li.txt"(file path) and in unicode the value returned the length of the path("c:\test\li.txt") and "c"(the path first character).
I am confusing about it long time. Is there anyone who has some thought about it, can tell me .
thanks advance.
lijie.
|
|
|
|
|
You're seeing just "c" because you're treating the string as if it were an MBCS string. The first two bytes are 63 00 (the UTF-16 encoding of 'c').
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
