Sorry your browser is not supported!

Ah - so thats what virtual.dat is for...

Some people have had a problem with the latest release, so I have posted a fixed replacement DBPro.hpp file on the interface library page on my site. Here is a direct link : http://www.matrix1.demon.co.uk/DBPro/downloads/DBPro.hpp

I'll work on this to make sure I can't make this type of mistake again

[EDIT]
For those still using Visual Studio 6, there is a new service pack available from Microsoft : http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp6/default.aspx
[/EDIT]

Ian, I've got a query and was hoping that you'd be able to help.

At present, I've decided to move all of my Thrust Engine code, specifically Cartography Shop map loading and the script processor to C++ (DevCpp v4.9.8.7. The problem is this. I've tried both including my DLL as part of the Plugins-User, and also dyanmically loading using LOAD DLL for running the C++ stuff I've done. All well and good, but debugging is another matter.

Are you aware of anyway to debug a DLL that is called from DBPro. Standard C++ applications isn't a problem since you just compile the App and DLL with debugging information and either run two sessions of DevCpp or run the DLL with a host application, but this doesn't seem to work with DBPro applications from what I can tell.

Basically, all I want is to execute my DBPro application that when calling a DLL exported function, it begins debug trace in DevCpp.

Any help on this would be grand, otherwise I'll have to resort to doing the debugging methods I did when writing DBPro applications alone.... ERROR_Push, ERROR_Pop tracing etc.

Cheers.

Paul.

Apex, this is exactly the method I've been having to use. Can get difficult at times.

I can debug a Visual C++ DLL within DBPro as long as I run it in a windowed mode, but I can't see a way to debug a Dev-C++ DLL.

It looks like you'll need to resort to file-based debugging for now. Sorry.

Ok guys, thanks anyway .... Oh well <sigh>

Paul.

DEBUGGING YOUR PLUGINS - A DevC++ guide.

Since the release of IanM’s Interface library, this has opened up a whole new area for development using DarkBASIC Professional, which in my eyes, is an excellent tool on it’s own. But developing fast image manipulation or mesh deforming functions in C does have it’s advantages.

Ok, I posted earlier asking the question about debugging DLLs. Finally, with a few emails to Lee, I’ve got a fairly good method of debugging DLLs using DevC++. Although the principle works identically with Visual Studio as well. This method of debugging allows you to place breakpoints in your DLL source code and trace through the code when your DarkBASIC application calls any of the DLL exported functions.

Unfortunately, the only way this can be done is by using the TPC SDK method. This means that your DLL must export it’s functions as addon DarkBASIC commands via a string table and that the DLL is compiled directly into the Plugins-User directory of your DarkBASIC Professional installation.

Although I have not tried this, I have been told that the above method is the only way that the DLL can be debugged. In otherwords, you can’t use Dynamic loading of the DLL using the LOAD DLL command from your DB application.

So, what’s first:

1. Well, start off as normal by creating your DLL, using the technical document that comes with DarkBASIC Pro’s help for adding user defined commands to the DLL via a string table. If you’re using C++, you’ll notice that the exported function definitions are mangled, but never the less, still work the same as normal C exported functions. Note that normal expansion plugins and plugins or DLLs that use IanM’s interface library work the same way.

2. When you’re ready to begin debugging your DLL, in DevCpp, select ‘Project Options’ and select the ‘Build Options’ tab.

3. Here, you must specify the Executable Output directory. Normally this is blank so it’s compiled to the project folder. You need to change this to the Program Files/Dark Basic Professional/Compiler/Plugins-User folder. **BUT** it needs to be in the Short hand form of the path, i.e. not using long name paths. So for example, on my machinee, it’s ../../../PROGRA~1/DARKBA~1/DARKBA~1/COMPILER/PLUGIN~1. Also note that although I’ve used forward slashs here, it needs to be the normal slash notation (Left key). I only did this here because of HTML tags.

4. Also under Project Options – Compiler tab, select the Linker options and enable compiling debugging information. By default, this is off.

5. Now do a complete rebuild of your DLL. The DLL will now be built into the Plugins-User directory.

6. Once your DLL is compiled, you must now compile your DarkBASIC Professional application. Doing so will automatically enbed the DLL with debugging information into your EXE. You must ALWAYS rebuild the DarkBASIC application after any changes to your DLL otherwise you will experience erratic errors from your DB program.

7. Ok, after your DB app is built, switch back to DevCpp and bring down the Debug menu. Select ‘Parameters’ option and ensure that ‘Host Application’ contains the full path and filename of your DB executable.

8. Now hit F8 to begin debugging. At first, your application will start but it will then pause. Switch to DevCpp and find the initial function that your DB application will call. I’ve found that debugging is temperamental when trying to get the debugger to stop, but the only way I could get it to do this was to place the Cursor in your source, onto the first executed line of the function. Do not place on variable declarations as these are precompiled. Maybe on a variable assignment or a function call. Anything!

9. Using the debugging tab at the bottom, select the ‘Run To Cursor’ button. Now, if you’re lucky and the breakpoint is valid, a breakpoint with a tick will appear in the gutter. If it does, select the Continue button on the debugging tab. You’re process line should hit this line and you can use the normal debugging keys to trace through your DLL code.

10. You’ll need to experiment with this but it does eventually work. What I will say though is that you can’t startup your debugging session if you’ve actually placed Breakpoints using Ctrl+F5. If you have, you’ll find that your DB application won’t startup. I think this is something to do with where the breakpoint is placed. If you have luck working this out, let us know.

Happy dabuggin.

Paul

In Visual C++, I do this, I expect it will work in DevC++ as well:

If you place the compiled DLL in the same folder as the executable, it will be used instead of the one in the plugins-user folder.

Hence all you need to do is set the C++ compiler's output folder to that of your exe, and then set the Host Application to your exe's name.

Then Compile and Run from your C++ IDE, and your DBPro app will be launched and you can debug it.

Cheers Rob, I'll apply the approach

Paul.

@APEXNow, I'm glad that you found a way to do this in Dev-C++.

I've got a slight variation on what Rob is doing. Visual studio is set up to automatically run my project when I hit F5 or CTRL-F5. Visual studio will then run the DBPro app to whatever break-point I have set in my code, so that I can single-step etc

Where I differ is that if I'm writing a program instead of a plug-in, my DLL will not have any resource strings set at all. I just use the CALL DLL system to run the program.

This allows me to use a standard DBPro app that accepts the DLL name as an argument on the commandline, meaning that I never have to write an app for it again.

Your method is by far a much better approach, although I've found some strange behaviour with the Dev-C++ Debugger when placing the DLL in the same folder as the executable. I'll experiment with this further but for the moment, my above approach is good enough to keep me occupied for a while. Eitherway, whether using Visual Studio or Dev-C++, at least we can debug the DLLs

Oh by the way, did you know that Microsoft have actually released their compiler under the EUNU licence. It's the same compiler that is distributeed with Visual Studio. Find at http://msdn.microsoft.com/visualc/vctoolkit2003/

Paul.

Yes, I'd been recently made aware of that on the General Discussion forum. I wonder if its compatible with the VS.NET IDE? I suppose I could try it out.

I do know that the libraries produced under 2003 are different to the 2002 ones that I produce now (I have access to 2003 at work), but I don't know how different or whether upgrading will cause a problem ... *sigh* so many things to try.


Anyway, the reason I'm posting now is to discuss my latest additions to the interface library ... I've adapted my system slightly to generate DLLs from user-plugins, and I've decided to use namespaces to avoid any clashes between the plugins available from different people.

I've currently got the following additional namespaces:

DBPro::Matrix1:: Data
DBPro::Matrix1::Network
DBPro::RobK::Gui
DBPro::RobK::Menu

I have permission from Rob to include his, but Rob ... do you have a preference to the namespace names that I use?

Also, is it a good idea to include these new namespaces within the DBPro namespace? Bear in mind that a simple 'using namespace DBPro::RobK;' would allow you to simply type 'Menu::CreateMenu("xyz");' later.

I also have had thoughts about getting rid of the 'OldString' parameter from the few commands that currently have it (or providing an addition function without it). What do you think? Is it worth the effort?

Discussion is welcomed.

If anyone wants to add their plug-in to the list, then just send me your plug-in and I'll include it. If for any reason you can't send the actual DLL (or don't want to) then a blank DLL with the resource strings compiled into it will do just fine.

I'm currently finishing up on my Cartography Shop file importer, which effectively adds fast CSM file loading through the DarkBASIC language. It will take about a week to finalise and test but I'll send it to you when it's done. It will probably need it's own namespace although this can be anything, even DBPro::APEXnow if required.

Anyway, I'll be in touch.

Paul.

I'll have a look through mine - most of mine are easier to rewrite in C (and would be more efficient). The only one I can think of at the moment would be the URLDownload one...

I know. I was having the same trouble myself.

Loads of plug-ins, but most of them will be better as a native function, but there's a fair bit of work there to sort that out

[quote]I have permission from Rob to include his, but Rob ... do you have a preference to the namespace names that I use?[/qupte]

I would use my "brand name" rather than my name, but its not really that important. Something like:

DBPro::Blue::GUI
DBPro::Blue::Menu

As something that might be worth mentioning, BlueGUI v2 has a totally different commandset and syntax, plus menus are built into the GUI rather than a seperate plugin.

I had exactly that same idea rob. It's currently being tested as 'Blue'.

There is no problem with your new Gui stuff. If you decide to use namespaces (which I suggest that you do, although it's a little more work), you can use a different one (maybe DBPro::Blue::Gui2 or something similar) to avoid name collisions.

You can always 'shorten' the namespaces anyway, not by 'using namespace ...' (something everyone tells you is a bad example and not to copy them), but 'namespace Gui = DBPro::Blue::Gui' to set up an alias.

IanM, and anybody interested. I've released my first Beta version of a plugin for DBPro that allows loading of CSM (Cartography Shop) map files. Visit my site for more details and downloading from the tools section.

@IanM - Thought you'd be interested in being credited for your excellent interface library

Paul.