|
No you are not.
for(i=0;i<9;i++)
T->currentCaseVector[i]='b';
for(i=0;i<9;i++)
c = T->PointersToNodes[1]->currentCaseVector[i];
You are initializing each member of the localy created T object. But you are readig the uninitialized members of a pointer to an object of type T, in this case '1', the second member in the array. Your BuildNewTree() function is not initializing the currentCaseVector array.
|
|
|
|
|
It is.
The function : resetCurrentCaseArray
do that work.(line 49)
SnaidiS(Semion)
|
|
|
|
|
Semion_N wrote: T->PointersToNodes[1]->currentCaseVector[i];(c is char).
c = T->PointersToNodes[1]->currentCaseVector[i];
Did you initialize the contents for this....
Two lines before this you write
T->currentCaseVector[i]='b';
in your code.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Yes I did intialized it.
I'm pointing from T to the array of pointers to Tic_Tac_Toe and thenthe object of Tic_Tac_Toe from the array. there is a currentCaseVector.
I intialized all.
SnaidiS(Semion)
|
|
|
|
|
So can anyone help me please?
SnaidiS(Semion)
|
|
|
|
|
I have already told you the answer. You are reading un-initialized data. Step through it with your debugger and keep your eye on the values.
|
|
|
|
|
Ok , Thank you , I will do that.
SnaidiS(Semion)
|
|
|
|
|
how can I assign this values then I could deside where and when to create and paint.
|
|
|
|
|
bloodwinner wrote: how can I assign this values then I could deside where and when to create and paint.
What do you mean? If you are talking about the sequence then WM_PAINT is called after the Window is created.
---
Hakuna-Matada
It means no worries for the rest of your days...
It's our problem free, Philosophy
<marquee behavior="alternate" scrollamount="5" scrolldelay="50">
|
|
|
|
|
You can generate these messages using the SendMessage API if you are asking about specifically sending these messages to some window.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Did you see MSDN? From the MSDN
WM_CREATE
The WM_CREATE message is sent when an application requests that a window be created by calling the CreateWindowEx or CreateWindow function
WM_PAINT
The WM_PAINT message is sent when the system or another application makes a request to paint a portion of an application's window. The message is sent when the UpdateWindow or RedrawWindow function is called
You can insert these messages from property window to your application.
|
|
|
|
|
and also you dont need to declare this function(WM_PAINT) its in your dialog and you can use from it (dc) for draw&write to context_device
|
|
|
|
|
I am using the IWEbBrowser2 Control in my application and its working fine. but my application requires that the Browser control doesn't write to the Global IE History list nor should itread from the cache. Can anyone give me solutions? I am simply stuck. Googled for it but found no answers....
Any sort of help would be appreciated.
Thanks...
---
Hakuna-Matada
It means no worries for the rest of your days...
It's our problem free, Philosophy
<marquee behavior="alternate" scrollamount="5" scrolldelay="50">
|
|
|
|
|
Ok. In VC++.Net 05, I've compiled a dll containing a namespace from one project in the solution. I'm now trying to use that namespace in another project but it is throwing up linking errors for the object it's compiled for the 2nd project. I have added the dll to the References in the Project Properties but nothing. If I say
> using namespace DllData
the compiler says that DllClass (in the dll) is not a member of DllNamespace. This makes sense as Intellisense is not picking up DllNamespace in the first place. I've tried including the headers for the dll source from the 1st project (which seems a bit counterproductive to me), which helps compiling the object code but then crashes the linker when it can't find the object code for the dll!
I know I'm doing something stupid or not doing something obvious. Please help!
|
|
|
|
|
Klempie wrote: I've tried including the headers for the dll source from the 1st project (which seems a bit counterproductive to me),
I don't know if I understood you weel, but you always have to include header files in which your classes are declared. Without that, you will not be able to use the class.
Klempie wrote: then crashes the linker when it can't find the object code for the dll
Crash ?? You mean really crash or you get linker errors ? Did you link the project to the library associated with your dll ? If you are linking implicitely to the dll (so, not using LoadLibrary and GetProcAddress), you need to link to the library containing the information about your dll.
|
|
|
|
|
Thanks.
On the header note, I mean for example that there is no include statement for framework dll's if they are referenced in the project properties. For example, there is no include statement for System::Data. It's just there if System.Data is in the references. Surely the same should apply to user-compiled dlls?
What do you mean by "link[ing] the project to the library associated with you dll". Perhaps this is the problem. How would I do this in VS?
|
|
|
|
|
Klempie wrote: System::Data
Errr... That looks like managed C++ . I am right ? If yes, you are in the wrong forum.
Klempie wrote: What do you mean by "link[ing] the project to the library associated with you dll". Perhaps this is the problem. How would I do this in VS?
If it is in C++, when you create a dll, there is always a lib file that is created with it. In your project that uses the dll, you need to link to this library (it contains the link symbols necessary for your linker to 'load' the dll). But in managed, I don't know if it is working the same way.
|
|
|
|
|
You are right. I am doing it in .Net. Wouldn't have thought referencing would change between them though. I will scoot over the other forum. Thanks for your help.
|
|
|
|
|
I have just ran over this Problem. I tried to pass a vector type as parameter in an RPC-Interface. But this does not seem to be possible. The reason i found was, that these classes have an internal memory managment that makes them impossible to marshal, since the use stuff like the "new"-operator to allocate memory, wich bypasses the client/server-provided memory allocation methods. Since i wanted to write a wrapper class for my RPC-Calls anyway, its not that big a problem, but i just wanted to ask if someone knows a more elegant solution.
MfG Mr.Brainley
|
|
|
|
|
another question:
when I create a window, I use function CALLBACK WndProc(), if another dialog box will be triggered by clicking a certain button in this window, I may use another function CALLBACK DlgProc(). if there is other more, I may use another CALLBACK DlgProc()....
could I integrate all those DlgProc() or ToolDlgProc() or other functions in WndProc()? then it may looks more simple.
I mean, all those functions looked the same:
like
LRESULT CALLBACK WndProc(....)
{
switch(msg)
{
case WM_COMMAND:....
case .....
}
}
BOOL CALLBACK DlgProc(....)
{
switch(Message)
{
case WM_INITDIALOG:
case ...
}
}
|
|
|
|
|
Typically, CALLBACK and WINAPI will determine the calling convention (__stdcall, __thiscall, __cdecl etc).
The functions do look similar, and they are performing similar tasks. A WndProc (window procedure) is designed to process specific messages passed to the window. If there are messages it does not wish to handle, then it can/should pass them on to the system default handler.
Similarly, a DlgProc will process messages passed to the dialog box. Again, if there are messages it does not wish to handle, it can/should pass them on to the default dialog box message handler.
That's one of the differences between them, and is why you can't really combine them into a single function.
In any event, having separate functions allows you to put behaviour specific to one window class into that procedure.
Steve S
Developer for hire
|
|
|
|
|
bloodwinner wrote: I mean, all those functions looked the same:
The return value of WndProc() is the result of the message processing and depends on the message sent. The return value of DlgProc() indicates whether the message was handled or not.
"Talent without discipline is like an octopus on roller skates. There's plenty of movement, but you never know if it's going to be forward, backwards, or sideways." - H. Jackson Brown, Jr.
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hi,
I have created an application using mfc and I got the exe in debug folder.
I took the exe file and placed in another system in which there is no visual studio software.when I tried to run the exe file I got the error saying that there is no MFC42D.DLL , c:\WINNT\system32;..........
How can I rectify this problem and run the exe file.
Can u Plz help me.
Thanks in advance.
|
|
|
|
|
First, you have to tell us which IDE you used to compile (VC6, VC2005, ...). Things are different dependending on the IDE you used.
To find which dll needs to be distributed with your app, open the dependency walker (the program is normally supplied with the IDE but you can find it easily on the web also). It will show you all the dll that your app requires.
Also, do not distribute debug version of your program (and dll). This is not legal (particularly for distributing the debug version of the microsoft dll's).
|
|
|
|
|
Thank you.
I have used visual studio 6.0 IDE
|
|
|
|