On Fri, 04 Sep 2009 04:40:51 -0400, Robert Jacques <[email protected]>
wrote:
On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <[email protected]>
wrote:
Thanks for yet another great release, but.. has anyone else gotten DFL
to compile? (The latest svn of DFL worked fine in 2.031)
I've been trying to get it up and running but I've been seeing really
weird errors. It appears in several cases that various import
statements are not being imported. For example:
import dfl.menu;
import dfl.form;
Seems to import the menu classes, but not the form classes. And
import dfl.form;
import dfl.menu;
does the opposite.
I tried tracing the issue down (from control.d -> menu.d ->
application.d -> form.d, testing using dfl.internal.winapi) and it
looked like I found a single line of code in form.d
version(NO_MDI) {} else {
// commented out source
}
in which a public import dfl.internal.winapi worked above and didn't
work below. But, when I tried to make a simple test case, everything
worked. And then when I came back to full source, that test worked too,
as did form (But that was only because I had publicly imported it from
application.d & application from menu.d)
With some more hacking, I've gotten it to compile. It appears to be
something to do in how cyclic (+ private duplicates?) imports are
handled. I made everything public and then commented out some of the
redundant imports. The strange thing is that I didn't have to remove all
cycles or all redundant imports to get it compiling. I did get a less
hacked up version running (package imports + removed redundancies), but
I had to turn off drag and drop support in order to get it to compile
and swapping around certain import statements still causes errors.
Well, I got drag and drop working. More importantly, I've manage to make a
small test case to put into bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=3301
