|
Do you see MSDN this event
when you press left mouse button or release left mouse button in noneclient area
if you click in scrollbar in your application you can see action from this event
And you need to OnNcLButtonUp or WM_LBUTTONUP
|
|
|
|
|
I have done what you said,result is failure
|
|
|
|
|
no its very simple you can click in scrollbar from your application and you get your messagebox
|
|
|
|
|
I am using C++ on Visual Studio 6, and now I want to work on .NET environment, so I am asking if there are differences between C++ on VS6 and VS.NET
Thanks a lot
|
|
|
|
|
Traitor 
Steve
|
|
|
|
|
I would be a tailor if I have migrated to C# 
|
|
|
|
|
Managed C++ is not C++ in my book; it's been twisted out of shape and is a sorry sight.
Steve
|
|
|
|
|
Is there a difference between programming for console and for Windows?
(that would be...YES)
After over a year, I'm still struggling to make the transition. I'm convinced MS has created .NET to basically get rid of all C++ programmers once and for all. Trying to make C++ run inside .NET is like putting training wheels on a Ferrari.
Kiss goodbye to pointers, they aren't allowed anymore, the idea of "data types" has becomes vague and confusing, .NET wants everything to be a strange nebulous "object" of indeterminate type and the new IDE has absolutely no idea how to organize things between .H and .CPP files. It now stuffs practically everything in one and leaves the other empty. Add to that the idea that we should no longer worry about allocating and freeing memory and leave that all up to some magic garbage collector.
Finally we don't actually make a real EXE file anymore, they've somehow decided that things run more efficiently with a "interpreted intermediate language"...gee, didn't we try that back in the days of DOS and BASIC interpreters? Then they realized compling programs into machine language was a lot faster and more efficient. Somehow here we are 20 years later going back to the slow crappy inefficient method, don't ask me why.
And if that isn't enough, only about half of the functions that I've come to rely upon and use have made it to .NET. The rest of the time I spend importing windows API functions with #DLLIMPORT calls.
You can switch if you like, I'm only using .NET when I can't do it with VC6 or get a real stubborn customer that demands it. When I do program in .NET I'm using C# because I just can't bear to witness what they've done to my good old C++.
|
|
|
|
|
I'm no .NET fan but there are lots of things you say which simply aren't true:
Phil C wrote: a "interpreted intermediate language".
MSIL is not interpreted; it is compiled. There are two main differences between typical compiled languages and .NET:
1- When the code is interpreted. With .NET the code is compiled to native code when the method is first executed. The process is called JIT compilation and the method is said to have been "JITed" when this has taken place for it.
2- You typically don't write a .NET application in MSIL directly. You write in a language like C# of even managed C++ which is compiled to MSIL by another complier. In this sense .NET applications are translated into native code by two compilers: the first is the language compiler which runs at build time and generates MSIL; the second is the JIT compiler which compilers at runtime and translates MSIL to the native machine code for the platform it's running on.
Phil C wrote: Kiss goodbye to pointers
I'm not sure on the details but I believe you can still use pointer using managed C++. You can have "unsafe" sections and even pin objects in the managed heap to you can safely "point to them".
Steve
|
|
|
|
|
Stephen Hewitt wrote: I'm no .NET fan but there are lots of things you say which simply aren't true:
Phil C wrote:
a "interpreted intermediate language".
MSIL is not interpreted; it is compiled. There are two main differences between typical compiled languages and .NET:
Hmm, well you are exactly correct. You have a much MUCH better command of the various details of it all than I do including the proper terms and how it's separated out.
However, I do know this for a dead on fact. I've now ported many of my old C++ workhorse functions over to .NET and the result is a program that runs many times slower (for whatever reason).
And yes, you can do pointers, you're right again. I've been forced to do all that many times now, but it's a huge pain and becomes even worse if you are trying to work with third party libraries some in managed and some with unsafe form because you have to carve out sections that are "unsafe". The pinning of object also does work and add to that the Marshal class to get access to managed memory objects...they did give us that.
But all of it still adds up to training wheels to the Ferarri in my opinion.
You see, my area is dealing with and managing various image data. Doing automated inspection, manipulating images from cameras, framegrabbers and looking for defects or whatnot. My programs spend a lot of time doing millions of calculations on big chunks of data. I've been recently forced to use .NET because my hardware has shipped with .NET libraries and I've come face to face with a lot of hard realities of how well/poorly the whole .NET scheme works under my conditions. The old "unsafe" C++ unleashed the true horsepower of the CPU to zip around huge amounts of data, deal with pixels on a byte by byte basis, convert from 8 to 10 to 16 to 24 bits/pixel with ease by using several differnt types of pointers into the same memory area, etc. etc. etc.
I could spend the rest of the day showing examples of hundreds and hundreds of lines of patches I've had to make to what once upon a time was nice clean code.
In conclusion I'll quote Jesse Liberty in the O'Reilly book - Programming C#:
While it is possible to program in .NET with C++, it isn't easy or natural. Frankly, having worked for ten years as a C++ programmer and written a dozen books on the subject, I'd rather have my teeth drilled than work with managed C++.
I couldn't agree with him more.
|
|
|
|
|
Phil C wrote: However, I do know this for a dead on fact. I've now ported many of my old C++ workhorse functions over to .NET and the result is a program that runs many times slower (for whatever reason).
I haven't used .NET much at all but I'm not surprised by its slowness. When one hears how it works it almost impossible to believe it could compare to C++ in speed or memory consumption. I'm no .NET fan.
Steve
|
|
|
|
|
Stephen Hewitt wrote: When one hears how it works it almost impossible to believe it could compare to C++ in speed or memory consumption
I can appreciate the candor 
I admit, I get crusty at times. It's just that all too often people seem to feel that just because something is new (.NET, managed memory, etc.) it's automatically better.
I'm not trying to say .NET and the managed memory model don't have a place and aren't wonderful for some applications. But in my world, which is generally standalone desktop programs that have no interaction with the internet, ASP, web pages, distributed SQL servers etc. etc. the extra layers of "stuff" do nothing but make things 10 times harder, slower and more complex.
If things keep going the way they are I'll probably become one of those (gag) Linux gcc geeks. LOL.
And I'll also be the first to admit that I don't always re-quote all the lingo, correctly. Anymore, the basic concepts of programming are all one big long techno-geek sentence that makes little sense to me. Sad when I think I really did have a pretty good grasp of all the compiling, linking, DLL's, libraries, includes, preprocessor directives, classes, pointers, heaps, stacks...and now I'm a idjut 
|
|
|
|
|
I have a function that is returning an integer, with a few strings being passed by reference. After running the debugger, it seems to run till I call the actual function that resides in a different dll. At that point I receive a window stating:
Unhandled exception at 0x0a30f6da in PCTest.exe: 0xC0000005: Access violation reading location 0xcccccccc.
The value of the external function in the debugger is 0x0a34310c and not 0xcccccccc.
I've set the permissions in the security to allow everyone, all access, (even the directory) but still access violation.
Here's my code, it seems simple enough, but I can not see it...
#include <stdlib.h>
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
int main()
{
typedef int(* PExportedFn)(char*,char*,char*);
HMODULE hmod;
PExportedFn ExFunc;
char char1ref[10],char2rev[10],char3ref[10];
int ReturnValue;
hmod = LoadLibrary("C:\\MYDIR\\EXTDLL.DLL");
if (hmod != NULL)
{
printf("Succeeded loading library");
ExFunc = (PExportedFn)GetProcAddress(hmod,"FUNC");
if ( ExFunc != NULL)
{
printf("Succeeded loading library");
wcscpy(char1ref, "1234");
ReturnValue = ExFunc(char1ref,char2ref,char3ref);
printf("Succeeded, return value is:%f",ReturnVal);
}
}
else
{
printf("Did Not succeeded loading library");
}
return 0;
}
Any help would be greatly appreciated.
Carl
Lucky_Carl
|
|
|
|
|
|
A callstack would be nice.
Steve
|
|
|
|
|
Hi LuckyCarl,
I have tested your code and it really not give the address of the function.
and got the solution for this.
As C++ by default mangles the name of the function and then link it as per my knowledge
if you create the function in the DLL using
extern "C", it avoids name mangling and function treated as C type function
so your function declaration should like following.
extern "C" __declspec(dllexport) int foo(char*,char*,char*);
and definition like
extern "C" __declspec(dllexport) int foo(char *f1,char*f2,char*f3)
{
...
}
and trying to debug the code for calling the fucntion from another dll
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
-- modified at 1:10 Saturday 6th May, 2006
|
|
|
|
|
I have debugged the code by creating sample DLL and an application uses it
now what i have faced that when am trying to debug the function called from another dll.The debugger avoids it and gives the result of the function and continue proceed further.
not fired any error as like you.
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
-- modified at 1:03 Saturday 6th May, 2006
|
|
|
|
|
Hello,
Is there a way for me to change the timeouts
assoicated with the CSocket class? In paticular I need to modify the
timeout used for Connect(). In my case, it takes about 15 secs for it to timeout now, and i'm working with around 25 sockets, so the time could add up if i'm unable to connect to any of them...
Note: I was using CAsyncSockets before, and all my connects came back with 'wsaewouldblock', which was ok, but the problem I was having is, after closing all the sockets (even one's that were not connected), and when the destructor cleans up, my program was crashing in 'sockcore.cpp' (Assertion failure). I do not see this problem switching to CSocket, thus the reason for the switch.
Thanks
|
|
|
|
|
arunkk1 wrote: I need to modify the
timeout used for Connect()
My socket is a little rusty so I may be wrong. I think timeouts are TCP/IP stack configuration settings. So they effect the entire machine. I don't think there is an API to change them directly. It is possible that there are registry keys and values that are OS dependent that contain the configuration. I also vagely remember the connection Timeout is not a straight time based mechanism but involves retry configuration that might be something like TcpMaxConnectRetransmissions.
Anyway if you do not get more specific answers here there are surly MSDN articles and Knowledge Base stuff on that.
"What classes are you using ? You shouldn't call stuff if you have no idea what it does" Christian Graus in the C# forum
led mike
|
|
|
|
|
Hey folks:
Right now we have an ASCII tab-delimited data file that is used in our applications. We really don't want the user accessing this file as they could really mess up the application by screwing up the data file.
Simply by making the file hidden is security by obfuscation, and we want someway of hiding the data.
Ideally, we wouldn't have to encrypt file, perhaps there's a way of preventing the USER from modifying this file, and only allowing our application to access it... someway of locking the file from the user?
I'm a C++/Win32 API newbie, so please make the answers appropriate for someone of my skill. Hopefully there is some easy way of doing this,
David
|
|
|
|
|
chasetoys wrote: someway of hiding the data
1) Host the data file in some directory where the user wouldn't easily find. For example: C:\WINDOWS\system32\foobar\data\
2) Rather than to store data in files, storing the data in the registry.
3) Use some fake name, for example "foobar.DLL", to name the data files.
4) ......
Maxwell Chen
|
|
|
|
|
Another alternative would by to put the data in the .EXE as a resource.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Another alternative would by to put the data in the .EXE as a resource.
1) If the data is increasing, the EXE increases the size then? (I guess YES.)
2) Personally I think that if the data size is relative too large (for ex: 800 MB), it would be not suitable to merge in EXE.
Maxwell Chen
|
|
|
|
|
I think yes increasing and I suggest use from one algorithm coding
|
|
|
|
|
My point is:
Let's say the EXE is now 800 MB as we use a smart algorithm to manage the resource in EXE.
But launching the program might take maybe 5 seconds because we used to have the anti-virus installed. And there is the On-Access scan.
Maxwell Chen
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
