Problems with programming on Delphi Win32 / Access Violation

Question

I was not sure what to call it, so I apologize in advance.

You see, I'm trying to teach myself Win32 / DirectX programming using Delphi (my language of choice) using this site - http://rastertek.com/tutindex.html

Of course, a site in C ++ should send it to Delphi. At first it seemed simple. I am in the second tutorial for DirectX 11 - setting up the framework and getting the original window.

Now for my real problem. I was getting access violation errors. So I found and started using MadExcept to try to figure out what was going on. So he tells me the lines, but I don’t know how to solve the problems.

I have everything configured to mimic, as well as the source code. The only real difference is that in cases where the class pointer is for a variable, for example, with m_input, m_grahics and the system, I made a type for them. So I have TSystemClass, TInputClass, TGraphicsClass, and then I have PSystemClass, etc., What = ^ TSystemClass, etc. I figured this would make things a little easier and more accurate. On the side of the note, I suppose it needs to be said, but to build copy constructors I made the initial classes inherit from TPersistent so that I could use it. Assign a procedure.

So, back to access violation errors. So, firstly, the problem was in the main program with a system like PSystemClass. Therefore, for an unknown reason to me, when I tried to use system.create, it was at that moment, creating an access violation. Then I realized that I did not assign a system.create system. So I tried it, and he said it, and I rightly assume that during compilation the error is that the two are incompatible, since system.create is of type TSystemClass and the system is from PSystemClass. So I tried to come up with this, and it worked. but again, still getting terrible access violations.

So, I had a strange idea, maybe I should have called a regular constructor directly from TSystemClass itself. And I tried, I need to come up again. So I did. And it worked! No more access violation error! Now ... A new problem! Rather, in this case, the "problem". There are three things that are now listed on the MadExcept call stack. First:

m_hinstance := GetModuleHandle(nil); 

He says that this causes an access violation error. Although why exactly this? From what I understand and read, if GetModuleHandle is set to null / nil, it should get a handle to the file that named it, right? And from what the documentation says, it should be executable.

However, a note: I'm not sure that the fact that I have the main program, the system class material, input material and the graphic class material are all in different program / device files to mimic the nature of the source code, So this may be the reason for this ? And if so, how can I fix it? Having put all the code from the module files into the main program file? Although this, in my personal opinion, would be rather dirty and unintuitive.

The next one puzzles me even more.

 InitializeWindows(ScreenWidth, ScreenHeight); 

I am not dealing with anything other than the function of registering a window class and setting things for the window, and that’s it. Therefore, I’m not quite sure that the problem is here, since it deals only with two parameters, and they are defined and everything is already before its call. Therefore, I am not entirely sure that the problem is in general and what exactly causes the violation of access rights.

and then finally the last is in the main program:

 return := system.initialize; 

The return is what I used in all instances of the result variable of the source code, because the result, of course, is an inline variable of all functions.

I believe that if the system can never correctly do what it wants to do, then something can / should happen here. Likewise, because I used to use TSystemClass.Create (typecasted to PSystemClass) to create a system that would do something here? And is this possible due to the other two, because they cannot correctly perform their own work?

And on the concluding remark; there is one last thing actually on the MadExcept call stack.

He says Kernel32.dll in the module section, but in addition to the main thread, it does not indicate anything. (If this information is needed, I will gladly express it).

Thanks in advance to everyone who read this far, and I hope to find help on this issue so that I can continue my studies.

Answer 1

You are creating your classes incorrectly. Here is an example from TSystemClass.Initialize :

 m_Input := PInputClass(m_Input.create); 

This is the variable you specified as PInputClass .

Earlier in TSystemClass.Create you initialized this variable:

 m_Input := nil; 

So, since you have a null reference, it should be clear that you cannot invoke any methods on it. In particular, you cannot call Create on it. Instead, call Create on the class you want to create: TInputClass.Create .

This constructor returns the value of the type you created, TInputClass . It does not return a PInputClass , so your cast type is incorrect. As Cosmin commented, Delphi object variables are already pointers. It is very rare to declare a pointer type based on Delphi classes. The correct code is:

 m_Input := TInputClass.Create; 

After this line, you check to see if m_Input is null. You should never do this in Delphi; the constructor either returns a valid object or does not return at all. If there is a problem with the construction of the object, the constructor throws an exception and the assignment operator is never executed. (C ++ source code also does it wrong. The new operator did not return a null pointer to crash for more than a decade, long before anyone was able to start writing a DirectX 11 tutorial.)

Answer 2

You should first try to get rid of TPersistent inheritance. If you want to pass an object to a library, its interface must be exactly the same as the original, which is used in C ++. Inheriting from TPersistent, you load a large load into your class that may not be needed or may even be the cause of your problems.

It also helps if you post the exact output of the exceptions. Or even CallStack. This can help track the error.