|
One more little thought to add to the above:
You can not change a String object. Replace
only deletes the old and creates a new object.
Once created the String is fixed. So -- if in
a loop changing a sting; be careful of using
String.
WedgeSoft
|
|
|
|
|
Hey guys, I'm trying to get a callback function to work from my unmanaged C++ dll. Everytime I run my program I get System.NullReferenceException saying "Object reference not set to an instance of an object." in mscorlib. This error is thrown when the runtime tries to execute the callback function in my unmanaged C++ DLL.
What I'm trying to do is real simple and straightforward:
namespace ProtocolDll
{
__delegate void MY_CALLBACK();
[DllImport("test.dll")]
extern "C" void UnmanagedFunc(MY_CALLBACK __gc* myCallback);
public __gc class Wrapper
{
public:
void myCallback()
{
MY_CALLBACK* cb = new MY_CALLBACK(this,&Wrapper::CallMePlease);
UnmanagedFunc(cb); // Call the unmanaged dll function
}
void CallMePlease()
{
Int32 i=0;
i=i+1; // I put a breakpoint here but it never makes it
};
}
************************************
Here is my unmanaged C++ dll code:
typedef void (*MY_CALLBACK)();
EXPORT void UnmanagedFunc(MY_CALLBACK* pfnCallback);
void UnmanagedFunc(MY_CALLBACK* pfnCallback)
{
(*pfnCallback)();
}
Any idea what I am doing wrong? Thanks for any help... this is my last issue with this unmanaged dllimport stuff... this code is a bear to write.
david
|
|
|
|
|
greetings...
im using borland 5.01 and i am trying to interconnect 2 computers with eachother over the internet.
i have to do it with windows (not linux), and it must be DOS (standard).
well, I have only 2 obstacles in my way so far...
1-does anyone know what functions exist for me to connect to a pc, knowing its IP address?
2-does anyone know what functions exist for me to obtain a pc's IP address, knowing its name?
oh, and to use these functions, what libraries must be included and where can i get them?
Thanks
|
|
|
|
|
I'm trying to call a C dll function passing a structure that looks like this:
typedef struct
{
long lModuleID;
DWORD dwAddress;
long lType;
BOOL fComplete;
long lLength;
BYTE *pbyData;
WORD wTimeoutMS;
long lErrors;
} MEMACCESS_STRUCT_S;
I translate this into the following structure in my managed C++ code:
[StructLayout(LayoutKind::Sequential)]
public __gc class MEMACCESS_STRUCT_S
{
public:
Int32 devAddr;
Int32 memAddr; // DWORD (UInt32)
Int32 type;
Int16 complete; // BOOL -> TRUE=1, FALSE=0
Int32 length;
Byte data[];
Int16 timeout; // WORD (UInt16)
Int32 err;
};
Everything works great except the variable "data" that holds the byte array. I get garbage when I look at the values for the array. What am I doing wrong? Thank you so much for any help... I'm nearing the point of headbutting my monitor and throwing my mouse out the window over this one!
david
|
|
|
|
|
|
Thank you for your help. I tried lots of different combinations using the MarshalAs attribute. I eventually ended up pinning (__pin) and assigning my Byte array to an IntPtr in the struct. That worked great!
david
|
|
|
|
|
to write two classes, screen and field, representing a screen
layout and an individual field (either a label or an input region) that
appears on a screen.
The field class, which lets us display, and possibly edit, a character
string, is really intended as a base class from which we'll derive many
kinds of field (displaying/editing different kinds of data) in the
future. Because of this, and because the code for the screen class will
use the field class extensively, it is important that the screen class'
logic uses only features of the field class described below and not
extra features you may decide to add to the field class.
When instantiated a field must be passed between three and five values,
in the following order:
- required: the row on which the field is to be displayed (int)
- required: the starting column for the field (int)
- required: the field's width (int)
- optional: an initial value for the field (constant character string)
- optional: editability flag (true: editable, false: display-only)
If only three parameters are specified, the field begins empty. If fewer
than five parameters are specified, the field is editable. Note that
instantiating a field does not cause it to appear - there are member
functions (below) to do that. If the coordinates specified are not
valid, the closest on-screen coordinates to those specified are used. If
the field width is too long to fit on the screen, the width should be
reduced so that the field fits on the screen. Similarly, if the initial
value is longer than the field width, only as many characters of the
initial value as will fit are used.
A field has the following public member functions, all of which are
virtual:
void display() - causes the field to be displayed on the screen. On
systems where terminal output is buffered, this function does
not flush the screen buffer. Note that if the field's current
value is shorter than the field width, trailing spaces are
displayed to fill out the field. (Such trailing spaces are not
considered part of the data of the field, however).
int edit() - causes the field to be displayed (as in display()) and
then lets the user edit the field, using the keys just as
dt_edit() does. The key code used to terminate editing is
returned. The first time a field's edit() function is called,
the cursor is positioned at the beginning of the field.
Subsequent calls to edit() start the cursor where it left off at
the end of the previous edit() call, unless the string is now
too small (in which case the cursor is positioned just past the
end of the string).
In the case where the field is not editable, this function
simply displays the field and returns 0 without waiting for any
keystrokes.
bool editable() const - returns true if the field is editable, false
if it is display-only.
void *data() - returns the address of the string currently stored by
the field. Note that we expect that in derived classes this may
be the address of some other kind of data being edited.
field *clone() const - dynamically allocates another instance of the
field, making that field a copy of itself, and returns the
address of the copy. If a copy cannot be made, this function
returns NULL. It is the caller's responsibility to deallocate
the copy.
Since dynamic memory allocation is required to implement this properly,
the field class also has an appropriate copy constructor, = operator and
virtual destructor.
A screen manages up to 50 fields (although if you can remove this limit,
you are more than welcomed to do so). The fields are kept in order by
when they were added to the screen - the field that was added first is
known as field number 0, the field that was added next is known as field
number 1 and so on. The screen class has the following public member
functions:
int add(int, int, int) and
int add(int, int, int, const char *) and
int add(int, int, int, const char *, bool) - adds a field to the
screen, where the field added is constructed with the data
supplied to add(). These functions return the number of fields
in the screen after adding the field, or 0 if the field could
not be added for some reason.
int add(const field &f) - adds a copy of "f" to the screen,
returning the number of fields in the screen after adding the
field (or 0 if the add() failed for some reason).
void display() and
void display(bool clear) - displays all the fields managed by the
screen, in the same order that they were added to the screen. If
"clear" is specified and true, the screen is cleared before the
fields are displayed, otherwise the fields are displayed without
touching any other part of the screen. On systems that buffer
terminal output, this function does not flush the output buffer.
int edit() and
int edit(bool clear) and
int edit(int *pfield) and
int edit(int *pfield, bool clear) - Displays all the fields of the
screen (after clearing the screen if "clear" is specified and
true) and then allows the user to edit them, starting at field
number "*pfield". The user moves between fields with any of the
following keys:
Down arrow - moves to the next editable field
Up arrow - moves to the previous editable field
Tab - works just like Down Arrow
Enter - moves to the next editable field, except when pressed
in the last editable field of the screen, in which case it
causes edit() to end.
Here "next" and "previous" refer to the order in which the
fields were added to the screen. There is a wrap-around effect,
also, so the the next field after the last field is the first
field, and the previous field before the first field is the last
field.
All other keys which terminate a field's edit() function
terminate this function as well, setting "*pfield" to the number
of the field from which the user exited. The key code used to
exit the field's edit() is returned.
If "pfield" is NULL or not provided, then editing starts at the
first editable field the first time edit() is called, and
resumes at the field last exited upon subsequent calls.
If "pfield" points to an int, but that int is not the number of
en editable field, then editing begins at the next editable
field (where "next" is as defined above).
If there are no editable fields on the screen, this function
returns 0 after displaying all the fields.
field *getfield(int i) - returns the address of field numbered "i"
or NULL if "i" is not the number of a field.
int remove(int i) - removes field number "i" from the list of fields
being managed by the screen, and returns the number of fields
left on the screen after removal. If "i" is not the number of a
field, then nothing happens and the current field count is
returned.
Note that removing a field renumbers the remaining fields.
Also, the += operator can be used, with a screen on the left and a field
on the right, to add a field to a screen, returning a reference to the
screen.
Note that creating a screen, adding a field to a screen, or removing a
field from a screen causes no immediate visual effect. It is when the
screen is display()ed or edit()ed that the user sees anything.
Note also that since adding a field involves copying the field, and
since we plan to derive new types of field in the future, you must make
the copies of fields by using clone(), rather than by relying on the
copy constructor.
Since this means that your screen must use dynamic memory allocation
(clone() dynamically allocates a copy), you should be sure to code an
appropriate copy constructor, = operator and virtual destructor for the
screen class.
Both the screen class and the field class should be declared in a header
file screen.h, and coded in a source file screen.cpp. Including screen.h
should also make the dtio functions available for use.
|
|
|
|
|
Do your own homework assignment.
If you are stuck with a particular detail then ask for help or advice with that. Do not ask CodeProject members to do your work for you!
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
thanks for replying me back
i am really thankful to you for replying me back.
i am not able to get started and figure out what all things have t be done in this i would be really grateful to you if you can help me in this actually i have source coude which will be used from some previous files i can send you that please tell me ur email address if possible.
|
|
|
|
|
I am coming up with an error of ...
h:\169\program 4\Part.h(52): error C2440: '=' : cannot convert from 'Vendor' to 'Vendor *'
and...
h:\169\program 4\Part.h(52): error C2440: '=' : cannot convert from 'Vendor' to 'Vendor *'
HOW DO I RESOLVE THIS...Here is my line of code it is referring to..
void setVendPtr(Vendor *c_VendPtr) { VendPtr = *c_VendPtr; }
Thanks so much!!!!
~Jason 
|
|
|
|
|
if VendPtr is a Pointer then only VendPtr = c_VendPtr;
because c_VendPtr is a pointer itself
|
|
|
|
|
How is this a managed C++ question ?
ISUstudent wrote:
{ VendPtr = *c_VendPtr; }
If c_VendPtr is a Vendor *, then * c_VendPtr is a Vendor, * dereferences the pointer. Remove the *.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
ISUstudent wrote:
void setVendPtr(Vendor *c_VendPtr) { VendPtr = *c_VendPtr; }
VendPtr seem to be a pointer.
two cases for you :
1 - you want to "link" the pointer in parameter to VendPtr. This way, VendPtr and c_VendPtr will point the same address :
<font style="color:blue;">void</font> setVendPtr(Vendor *c_VendPtr) {
VendPtr = c_VendPtr;
}
2 - You prefer create a new copy of the datas pointed to by c_VendPtr and point VendPtr to this new adress :
<font style="color:blue;">void</font> setVendPtr(Vendor *c_VendPtr) {
VendPtr = new Vendor;
*VendPtr = *c_VendPtr;
}
I personnally prefer the second method...
TOXCCT >>> GEII power
|
|
|
|
|
Excellent...I got it!
Thanks a Mill!
|
|
|
|
|
void setVendPtr(Vendor *c_VendPtr)
{
VendPtr = *c_VendPtr;
}
VendPtr // undeclare is a long, so you cannot assign it this way !
void setVendPtr(Vendor *c_VendPtr)
{
Vendor VendPtr;
VendPtr = *c_VendPtr;
}
|
|
|
|
|
Hello all.
I have decided to change the output directory of my managed c++ application and also the intermediate directory.
I had as output and intermediate directories de defaultvalues:
OutputDirectory="$(SolutionDir)$(ConfigurationName)"
IntermediateDirectory="$(ConfigurationName)
which in fact were the same directory.
I have changed this right now to:
OutputDirectory="o:/$(ConfigurationName)"
IntermediateDirectory="o:/$(ConfigurationName)/Intermediate/$(ProjectName)
This changes the output of the project and the project is build correctly but when I try to execute the application I get a System.Resources.MissingManifestException.
If I don't modify the original value for the intermediate directory it works fine
Please can anyone explain something to me ???
Thanks in advace.
|
|
|
|
|
HI Fellow Aliens, try this one for size:This problem came from an international programmers contest, only one team made it....and finished in 4 hours! Well done New Zealand. Can you keep up with this problem?
Problem:
You are given an unknown number of composite blocks composed of 1 inch cubes. The one inch cubes are labeled with X,Y,Z coorinates. Facing each block, the x coordinate denotes the columns, the y coordinate the rows and the Z coordinate the depth. Each face of the one inch cubes is labeled with one of the color codes A,B,C,D,E or F. The face toward the vi   ewer is A, then moving to the right side, back side, and the left side, the faces are labeled B,C and D. The top face is labeled E and the bottom F. In addition to the labeling, two of the one inch cubes are designated as "Start" and "stop"
The task is to determine if a path exists from the START to the STOP cube in each composite block. In order for a path to exist, you must be able to move from one internal cube to another via the sides with matching color sides.
Input: Input for each composite block consists of the X,Y,Z coordinates of the cubes, and the colors of the cube faces. The X,Y,Z coordinates for each cube represent the rear left lower point of the cubes. Assume a right hand coordinate system, is used and individual values for X,Y,Z will be less than 256. The colors are organized from left to right with the front face first, then the right, back, left, top, and bottom faces. The first two lines of data for each composite block represent the coordinates of the START and Stop cubes and the color codes of their faces. Negetive ones seperate the data sets for each composite block and there will be an unknown number of data sets in the file. Each composite block is to be treated as a seperate problem. The input file is named "maze.dat" and has the following appearence.
Items in braces are not part of the input:
{X Y Z FACES}
{START-->} 000ABCDEF
{STOP-->} 222CDEAFB
010FACDBE
020EDABCF and so forth.
OUTPUT:
Your output shoudl consist of a label for each block, and a statement indicating whether a path exists from the START to the STOP cubes. If more than one path exist, the paths should be presented from the shortest to longest.
PROGRAM LAUNGUGES ALLOWED: C++ or JAVA.
GOOD LUCK! BET YOU CAN'T BEAT THIS ONE!!
|
|
|
|
|
Hi to All,
I have a program in Managed VC++ and I want to add some Graphical Routine to
it. I have seen the C# code and its quite similar to Managed C++. All
functionalities in C# i could use in MVC++ except Managed DirectX. I always
get a compiler error, when all im just trying to do is create a device eg:
Microsoft::DirectX::Direct3D::Device* device;
...
PresentParameters* dxParams = new PresentParameters();
dxParams->SwapEffect = SwapEffect::Discard;
dxParams->Windowed = true;
device = new Device(0, DeviceType::Hardware, this, CreateFlags::SoftwareVertexProcessing, dxParams);
Can Managed DirectX SDK Summer 2004 be used in MVC++ 2003?
Please help me out on this coz im quite desperate...
Here's the error code:
error C3635:
'Microsoft.DirectX.PrivateImplementationDetails::IDirect3DDevice9': undefined
native type used in 'Microsoft::DirectX::Direct3D::Device'; imported native
types must be defined in the importing source code
did you forget to include a header file?
(NOTE: I've already included all the necessary assemblies)
cheers 
--
Paul June A. Domag
nth geographics and geometrics
|
|
|
|
|
pauldomag wrote:
I have seen the C# code and its quite similar to Managed C++. All
functionalities in C# i could use in MVC++ except Managed DirectX.
Why on earth would you use MDC instead of just plain old DirectX ?
pauldomag wrote:
did you forget to include a header file?
(NOTE: I've already included all the necessary assemblies)
As the error is telling you, you apparently are missing some header files.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Hi Christian,
Im using Managed DirectX over the Umanaged one coz, as the name implies it is easier to manage...
All of the samples included in the Summer 2004 SDK are in C#...
But as you can see, the idea of the .NET Architecture is to be able to develope in cross languages so I think, Since Im using Managed C++ I should use Managed DirectX...
But the problem is Im getting some kind of error...
But viola! i've solved it... A person kind enough answered my question..
Just create a header file, with this content:
namespace Microsoft {
namespace DirectX {
namespace PrivateImplementationDetails {
__nogc struct IDirect3DDevice9 {};
}
}
}
And simply include it in your .cpp file..
cheers
Paul June A. Domag
nth geographics and geometrics
|
|
|
|
|
Sounds like a hack to me. Surely you're working around either a problem with the SDK, or a problem with your setup.
Either way, COM talks to .NET with no worries, there's no reason in the world to use Managed DX ( especially as managed means simply that you can fall into a false sense of security and slow your system to a crawl if you don't manage your own memory ).
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Well I guess its the problem of the SDK. coz some people I know also experienced this kind of problem (Thats why some of them shifted to C#)...
I personally agree with you on the performance issue. But im not actually developing a game or something that needs the extra speed of an unmanaged DirectX... thats why im using the managed one...
I guess COM do talk to .NET with no problems. But as I see it, when you access COM in your .NET app (C# or VB .NET) what the framework does is automatically create COM Wrappers on the objects so that you could access it. And thats an extra layer that your application needs to pass to be able to access COM. And I guess it would drag your app a little bit. Well, I read an article in microsoft that suggests that if you would like to create an app that is based on COM, better use Visual Studio 6 instead of VS .NET
Thank you very much Christian, for your comments and great insights...
cheers
Paul June A. Domag
nth geographics and geometrics
|
|
|
|
|
pauldomag wrote:
And thats an extra layer that your application needs to pass to be able to access COM. And I guess it would drag your app a little bit.
Surely you realise that layer has to exist somewhere ? I doubt they rewrote DX entirely for managed use. I hope they didn't, it would be very bad practice. Unless a sub COM layer already existed, I suppose.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Greetings Christian,
Yes your right Microsoft didn't rewrite the DX for managed use. Instead they added a set of assemblies to be able to comply with the .NET Framework (thus came Managed DirectX). The classic style DX (unmanaged) is still there... By the way, you could also mix both worlds (eg unmanaged DX in managed) or just like my friend vas, he uses unmanaged DX and everything else is in .NET (forms..etc) Well i guess you could get the best of both worlds...
cheers
Paul June A. Domag
nth geographics and geometrics
|
|
|
|
|
Hey everyone. I just need to know how to make a cube bounce off the borders of the screen in DirectX 9. I'm currently reading the "Introduction to 3D Game Programming with DirectX 9.0" book - but I can't figure out how to make a cube bounce around the screen. I would like to eventually make it so that a cube, torus, and teapot bounce off the borders of the screen in different directions and speeds. Can anyone help me and provide some code with explanation? Thanks!
<3, Guissella
motobmxdiva@yahoo.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
