Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Variable Trace Program

Author
Message
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th Aug 2014 22:20 Edited at: 30th Aug 2014 22:27
I haven't had time to code in DBC for about 2 years now and I realize I'm starting to forget a lot of the language and those things or methods I liked most: dealing with "limitations" or approaching interesting or tricky challenges.

I started going through my files today and came across a ton of code snippets and programs I had written. So many have no remarks and do something, but I can't remember what I was trying to test or prove. It kind of made me sad.

I did however, come across a program I wrote that would trace variables in a DBC program and output their values to a console screen in real time and also create a log file of their changing values. Fortunately, I had completely documented this one.

It's meant to be a library that can be added to any program. The main posting has an example in the middle of capturing specific values for a rotating cube. To use the library in other programs, just rem out or delete the following example code before the start of the library functions:



Here's the complete code. Hopefully someone finds it useful. If you run it with the example code, RIGHT CLICK the mouse to stop the program and the trace. You may have to drag the console screen out of the way to view the cube. Keep in mid, you don't have to use trace_open() if you do not want to save a trace file. The output is always sent to the console.



Enjoy your day.
Libervurto
14
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 31st Aug 2014 00:30
I never got into DLL's, which is a shame because they seem to really get under the hood of DB.

I turned my nose up at these lines

if tracefile(1)=0 then kernel32=0
if kernel32=0

But you probably have good reason for the separation, such as a case where tracefile(1)>0 and kernel32=0.
This is more a note for newbies now, that you must be sure of exactly how the code is behaving, not just it's most obvious features. Two pieces of code that act the same in one case may behave differently in another case.

Formerly OBese87.
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 31st Aug 2014 09:31
Hello,

for me, I wanted the global variable identified to the trace library, so it is an array named tracefile(n). Inside the function, I want the local variable identified to the dll it is assigned to, so it's named kernel32. The conditionals test for the local variable and the global variable being set (a non-zero value).

I "left room" in the test to make sure that if initialize is called a second time (by accident or for some reason deliberately), the value of kernel32 or tracefile(1) could be checked for an initialized state. The full test I had in mind isn't included in this code. Currently, the initialized state is only controlled with the test on tracefile(1)=0. This also means I could use other DLLs outside of the function and change their dll numbers to whatever I want, even the current local kernel32 number in the function. If I am using other dlls, then I would have to remember to set the global tracefile(1) back to 0, and call the trace initialize routine again. This would automatically reset the kernel32 dll number to 0, then search for the next available dll number which means I don't have to manually control or set the dll for the trace routine. The shortcoming with this, the way it is currently coded, is that there is a possibility of having the actual kernel32.dll assigned and loaded as 2 numbers. However, if in the global environment when I want to use that dll, I should now that running the initialize routine sets the global variable to the kernel32.dll that is loaded in the function and therefore, there wouldn't be two assignments for the same dll.

Often (in DBC) I use local variables to test for states of the function. In this case I had in mind to allow the global array to change but to use kernel32 as not only the value for the dll, but as a flag that the state of the function had changed. I don't have those additional tests in the code, but the foundation is there for future changes. I never got around to changes or additions. One plan was to have the entire library in one function.

So believe it or not, I actually had some logic for the use of:



Enjoy your day.
Silverman
13
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 2nd Sep 2014 14:18
Quote: "dealing with "limitations" or approaching interesting or tricky challenges"

Agree, it is also my motivation with this language.

You have made ​​a interresting piece of code, it will be much helpful.

DirectX 9.0c (February 2010)/ DBClassic v1.20

Login to post a reply

Server time is: 2020-08-12 01:56:45
Your offset time is: 2020-08-12 01:56:45