Sorry your browser is not supported!

Sorry about the lack of information or not well written info. I am not exactly sure how to fully explain everything. Also, sorry about my slightly bad English. I will have a demo posted up very shortly, most likely by tomorrow morning with full documentation.

About:

Dark NET allows you to use the .Net Framework version 2.0 in your DarkBASIC project. All commands must be hand written by me, so not every command will be included. Most commands will be available over time, and some commands will not be included because of DBP incompatibility.

Dark NET will be a language in itself, DBP commands can be used along with Dark NET commands but Dark NET will not be able to access the DBP window (program stream) itself. The original DBP commands do are not changed in any way, and can be typed and used like normal. You will, however, need to embed the DBP window inside of another windows form in order to have access to the form (window) DBP is located on. You will be able to do this in a single command, or you could even code it yourself. All the command will do is dock the DBP window inside a picture box that is located on another window. The picture box can them be the full size of the window (does not have to be though), making the DBP window not look different at all. I know this sounds odd and complicated, but like I said before, I am not sure how to explain it well.

Dark NET will feature thousands of new commands. Using Dark NET you can write full .Net applications that have the speed and compatibility as if you wrote them in .Net yourself. Write anything from console applications to full multiple windowed form applications. I have tested a lot of commands so far with speed tests. Each test consisted of executing 500 different .Net commands one right after the other with the speed calculation being the time when execution started to the time after every command had executed and completed. The average speed loss was 9 milliseconds per second.

Dark NET will be a series of large DLL’s, each of them must be paid for separately. None of the DLL’s are finished as of now. The system framework DLL is the DLL currently being worked on. Why are the DLLs so large and why must they all be paid for separately? For those who have used .Net, this is a no brainer. The system framework is very large. It covers consoles, threading, application control, security, windows forms, and much more. The windows forms framework will be similar to BlueGUI, but have nearly 3x as many commands and gives you full control over windows forms, and that’s just that single framework.



Debugging:

You will have full .Net debugging with most functions. There are 2 debugging options with each DLL. Other debugging, which is debugging of everything but functions, and function debugging, which is the debugging of the actual functions themselves. Most functions will not cause any program errors when they fail. They will silently stop without anything happening. When function debugging is on, full debugging info will be printed out to the console screen if and when a function fails. You will get the same messages as if you programmed them in any .Net language. Debugging will handle exceptions such as IOException, OutOfMemoryException, ArgumentOutOfRangeException, FormatException, ArgumentNullException, SecurityException, HostProtectionException, ArgumentException, and most of the other exceptions in .Net.



Frameworks:

The frameworks that I have planed to be included are the System framework, the DirectX framework, the Data framework (XML, SQL, etc), and the Networking framework (most likely will be a part of the data framework DLL).



System Requirements:

* A .Net supported operating system:
Windows XP with Service Pack 2
Windows Server 2003
Windows 2000 with Service Pack 3
Windows ME
Windows 98 Second Edition (SE)
Windows 98
* Microsoft .Net Framework version 2.0 or higher
* DLL's tested with versions 6.0 and 6.1 of DarkBASIC Professional
* Any requirements that are required by DarkBASIC Professional (DirectX 9.0c, etc...)

Nice...
Nice...

looking forward to more info.

Would be very good, but you keep saying 'will'. There isn't anything to prove to us that you have actually done anything. Although I believe you have

Yes this is really being made. I am the only developer so yes it will take quite some time. ZKAT8IT, the guy who makes the .Net DLL converter, would agree this is being worked on. This project didnt start out as a real project, but something to test his converter with (i am the official tester of his application). Once I found out I could make such a series of DLL's I decided to do it. Yes it is hard, yes it is a very large project, and yes it will take a long long time, but it is being made.

You can actually grab my really old demo of the old version of the DLL that was posted here at TGC in the darkbasic professional dicussion section. I had about 65 downloads and a few users commented and told me it works well. So, they too can say this is really being worked on.

I dont blame you for the little doubt though. It is a large project

Cool

Pre-Release 1.0.0.0

This post contains a pre-release. A pre-release is a fully functional DLL package with some of the currently finished functions. These pre-release downloads are available so people can learn the DLL's as they get bigger. I figured learning a little bit at a time will allow people to learn much easier than having the whole large DLL right away. These pre-release's also allow me to fix bugs early if anyone should run into one.

Total Functions - 25

Documentation - Full function documentation on all 25 commands.

Keywords and Constants File - Yes

Example Code - No

Frameworks - DLL Framework, Console Framework

Application Types Written and Tested - Stand alone console application, console added to a standard DBP game, console added to a standard DBP game with full .Net and DBP game debugging and standard key/full string input.

Debug Speed Test

This post contains a debugging system speed test. You will need .Net 2.0 to run it. It tests both error to console and error to file functionality. Each type of error output is done 2000 times and timed, with the end time result being printed to the screen in miliseconds and seconds.

What happens each of the 2000 command executions? I call System_CustomBeep 2000 times, each time with the same invalid values giving me an error message every time. Because there is an error message each time, the DLL must catch the error, cancel the function, convert the error to a string, pass it through .net, then handle the error as I tell it to. If I tell it to print to the console, then it will print the error 2000 times. If I tell it to write the error to a file, then it will create a file in the debug directory, name it, write to it, then close it each of the 2000 times.

The code to the speed test(uses paid only functions):



By the way, sorry there is no update to the DLL. I was on vacation and only had time to think about this project rather than work on it. I came up with a good addition to the debugging system which I have finished. I added the ability to write errors to a file rather than to the console so an error message doesnt print when you dont want it to, but you still want to debug functions and the DLL. The speed test covers both file writing and console writing aspects.

Oh yea... I know I said 5000 lines in the code/demo... I meant to say 4000.

Never mind the post that use to be here... I found out you can run into serious errors when I had option 2 implemented... so option 1 is the only option. If you wanted to know what the options were, my origional post is in the quote box.