Thanks for the feedback from the previous article, I know now that:
- DFL should work with the BCL in D2, but it just doesn’t at the moment, due to some repository snafu…
- Visual D had building problem due to… tool chain issues! This page about Visual D known issues explain what’s going on and how to fix it!
Hence by modifying C:\D\dmd2\windows\bin\sc.ini
To be like (changes in maroon)
version=7.51 Build 020
LIB="%@P%\..\lib";\dm\lib;%DMD_LIB% DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import"
I was able to make do with a much more satisfactory config:
Maybe I should mention that D, despite being a marginal language (as in: little know) has a surprisingly pleasantly vibrant community support.
Also the Digitalmars page on D is full of interesting link (particularly Tools => More Tools) but I’d like to grab the attention on 2 communities:
- D Source forums
- Digitalmars newsgroups (news server: news.digitalmars.com). Can be accessed with Windows Live Mail or Thunderbird for example. Just create a new newsgroup account
Initial sample reloaded
I though it might be a good idea to have DGui in my projects (i.e. as source code / solution’s project) and link my test project against it. This way I can look, play with and learn from some D code written by a more knowledgeable D programmer than I!
It turns out there are key difference with what would happen with trying to do that with C#. Perhaps it behave like it will with Visual C++, I couldn’t tell, not having using it enough…
At any rate here is what happened
- I created a new Visual D static library
- Created the directory hierarchy of the DGui source (it’s important for D, just like Java, it reflects package organisation)
- Added the existing file from DGui
- And build, successfully first try! (Nicely enough DGui has no other dependency that Phobos / BCL)
Now, when looking at the file system, there was no D file in my project’s directory! All these files in the solution explorer linked to the one and only original files.
Hence, I shouldn’t change the import file path of my test project. For the record they remained pointing to
Updating the dependencies
But I still needed to point to my build version of DGui, hence change the library path of my test project. And I also need to set my test project to depends on my (local) dgui project.
Right click on project => Project dependencies => select dgui
Set the library search path to the project build location: C:\Dev\DTest\dgui\Debug.
F5, it builds and run!
Now for the surprisingly good part, in my test app, if I F12 on one of the class I use, VS actually goes there!
But no method list (yet?).
Just for fun I added a “std.stdio.writeln("hello");” in initialization looking method (I still knows nothing of D, hey!) and .. it printed!
Getting rid of the console
I’m trying a GUI sample, yet I have a nagging MS-Dos console appearing every time I run. To get rid of it I should pass a special flags to the linker (in Additional options) so it will mark the executable as being a windows application (i.e. no console attached!)
A brief look at the source code
So far I haven’t coded anything yet! Just wanted to feel comfortable with the development experience… But will post about source code next time!
Anyhow, below is the source code of my test app (straight from events.d in DGui’s samples):
class MainForm: Form
private Button _btnOk;
this.text = "DGui Events";
this<.size = Size(300, 250);
this.startPosition = FormStartPosition.CENTER_SCREEN;
this._btnOk = new Button();
this._btnOk.text = "Click Me!";
this._btnOk.dock = DockStyle.FILL; this._btnOk.parent = this;
private void onBtnOkClick(Control sender, EventArgs e)
int main(string args)
return Application.run(new MainForm()); }
The exciting things I can see from a quick look at the source is that D supports properties, events and DGui looks quite similar to WinForm!
Except for the lack (at the moment) of designer
Ho well, I just plan to make simple wizards anyway…