|
Be more specific please.
What kind of application (project type, the functionality, etc.)?
Under what OS?
......
......
Maxwell Chen
|
|
|
|
|
My apologies...
Its a MFC (no .NET project)... target install base are WinXP computers, but I'd like it to run on 98SE and up. I tried to link everything statically.
The user who tried installing it had WinXP Pro SE installed.
Could the error be that I didn't specify which version of Windows I wanted it to work on in the header files? I.e. I didn't have:
#define WINVER 0x0410
or
#define _WIN32_Windows 0x0410
Would this have fixed it?
|
|
|
|
|
|
maybe you use from resources that are only in your windows
|
|
|
|
|
I want to connect mobile communication with my program
how to do this;
|
|
|
|
|
narkhi wrote: I want to connect mobile communication with my program
Do you mean that you are planning to implement WiFi client in your code?
Maxwell Chen
|
|
|
|
|
|
void CMyListCtrl::OnNcLButtonDown(UINT nHitTest, CPoint point)
{
// TODO: Add your message handler code here and/or call default
if(HTVSCROLL == nHitTest)
MessageBox("LButtonDown On Vertical Scroll");//Here is OK
CListCtrl::OnNcLButtonDown(nHitTest, point);
}
void CMyListCtrl::OnNcLButtonUp(UINT nHitTest, CPoint point)
{
// TODO: Add your message handler code here and/or call default
if(HTVSCROLL == nHitTest)
MessageBox("LButtonUp On Vertical Scroll");//No MessageBox. what should I do??
CListCtrl::OnNcLButtonUp(nHitTest, point);
}
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
