www.digitalmars.com         C & C++   DMDScript  

D - Type Name Proposal

reply Lewis <dethbomb hotmail.com> writes:
Id like to submit a proposal (feel free to shoot it down)

Theres millions of lines of code written (mostly in vb and delphi) for COM, and 
its an open standard still widely in use. With the poor support for COM in .net 
(they want you to use managed .net components now) alot of that code may lay 
around unused but still useful. Using an ocx in windows as a plugin for your
app 
is the best current way to go if your not coding in .net...

So anyhow, the point im trying to arrive at is that COM is still a viable 
technology for years to come but isnt supported well in most low level 
languages... My proposal is to make the COMObject built in to D, in such a way 
that the garbage collector doesnt interfere with its reference counting, and 
that D auto calls AddRef() and Release() any time a reference is instantiated
to 
it. Also id like to propose a new name, instead of ComObject call it
Component...

Was an idea i had, but since im inexperienced with how this language works it 
maybe best to keep it at lib level... but thought i would suggest it...
Dec 16 2003
next sibling parent davepermen <davepermen_member pathlink.com> writes:
com objects are supported in D

In article <brmnet$as9$1 digitaldaemon.com>, Lewis says...

Id like to submit a proposal (feel free to shoot it down)

Theres millions of lines of code written (mostly in vb and delphi) for COM, and 
its an open standard still widely in use. With the poor support for COM in .net 
(they want you to use managed .net components now) alot of that code may lay 
around unused but still useful. Using an ocx in windows as a plugin for your
app 
is the best current way to go if your not coding in .net...

So anyhow, the point im trying to arrive at is that COM is still a viable 
technology for years to come but isnt supported well in most low level 
languages... My proposal is to make the COMObject built in to D, in such a way 
that the garbage collector doesnt interfere with its reference counting, and 
that D auto calls AddRef() and Release() any time a reference is instantiated
to 
it. Also id like to propose a new name, instead of ComObject call it
Component...

Was an idea i had, but since im inexperienced with how this language works it 
maybe best to keep it at lib level... but thought i would suggest it...
Dec 16 2003
prev sibling parent reply "Matthew Wilson" <matthew.hat stlsoft.dot.org> writes:
 Id like to submit a proposal (feel free to shoot it down)

 Theres millions of lines of code written (mostly in vb and delphi) for


COM, and

 its an open standard still widely in use. With the poor support for COM in


.net

 (they want you to use managed .net components now) alot of that code may


lay

 around unused but still useful. Using an ocx in windows as a plugin for


your app

 is the best current way to go if your not coding in .net...

 So anyhow, the point im trying to arrive at is that COM is still a viable
 technology for years to come but isnt supported well in most low level
 languages... My proposal is to make the COMObject built in to D, in such a


way

 that the garbage collector doesnt interfere with its reference counting,


and

 that D auto calls AddRef() and Release() any time a reference is


instantiated to

 it. Also id like to propose a new name, instead of ComObject call it


Component...

 Was an idea i had, but since im inexperienced with how this language works


it

 maybe best to keep it at lib level... but thought i would suggest it...


D's COM is ripe for some attention, and will likely get it in the new year.
If you can be more fulsome in describing your ideas, it'll give us something
to think about, and possibly incorporate.

Cheers

Matthew
Dec 16 2003
parent reply Lewis <dethbomb hotmail.com> writes:
  > D's COM is ripe for some attention, and will likely get it in the new year.

 If you can be more fulsome in describing your ideas, it'll give us something
 to think about, and possibly incorporate.
 
 Cheers
 
 Matthew
 


Thanks for the encouragement matthew :)

(be forewarned: this may be the longest post i ever make here)

Let me start by first clarifing where i come from, and why i say some of the 
things i do (albeit probably ignorantly in context to D most of the time)
Ive only ever programmed in visual basic and for windows. In the vb community
im 
known as one of those "optimizer freaks" that is never happy with the fact that 
code works. It must work extremely well, as fast as is possible using any api
or 
assembly hack we can find or write, and generally as error free as possible
even 
if it requires more lines of code... Between some injected assembly and api 
useage, i can, in alot of cases create code that runs as fast (an sometimes 
faster) than a program that does the equilavent in c++. By using assembly 
injection, I can also call C dll's from visual basic (something microsoft will 
tell you is impossible) but...
(speaking in general from here >)
With us "vb freaks" its a old war to prove that vb is in fact more than a toy 
language (and it has been proved in my opinion) and for basic gui windows-only 
apps, i still believe its the fastest solution in most cases, but theres
several 
things that are missing from the picture...

We often secretly admire the fact that c/c++ programs dont have a runtime they 
have to drag along, or require the user to download a 1 mb+ runtime file (or 
worse the .net framework) and also very few of our programs will run on 
alternate operating systems (wine still has a way to go on that) , and visual 
basic isnt cheap, (900+ for enterprise version)...

This along with the fact that microsoft has basically abandoned 'pure' vb 
programmers (i think few will argue that switching to vb.net from vb6 is almost 
akin to learning a new language) and the millions of lines of COM code we have 
now lying around... Its time to look elsewhere. Alot will probably go to delphi 
since its the closest competitor to vb's language and rad IDE (and has great 
support for COM), but myself i just cant do it, i decided if im going to learn
a 
new language im going to learn one that gives me the power to be flexible,
cross 
platform to an extent, and allow me to not be stuck with one technology... Most 
of the vb programmers dont want to use delphi or c++, (they've been enemies to 
long 'tongue in cheek'), so D offers a nice way out ;)

When the last upgrade to the .net runtime was, once again, incompatible with
the 
first .net runtime, I decided (in a moment of disgust that involved deleting 
.net, and mumbling anti-corporate rantings), that i was going to learn a lower 
level language and write an interpeter for basic that supports COM instrinsicly 
similar to visual basic. It would take my basic code with some alterations and 
convert it to the lower level language automajically. (in other words a BASIC 
replacement for D's frontend) This allows for several things immediately, 1) a 
promise for some portability, and 2) no required huge runtime file and 3)
easily 
do things that were hard or impossible to do in vb.

BCX, (and Pavel Minayev's B++) have gone along way towards this goal but both 
have very little support for COM, something i want to support in mine very
well...

My first option of course was to furthur learn more assembly, and i decided to 
forget that angle its just more than im willing to commit to for now, the
second 
option was C and that fell in the same catagory as assembly... it just requires 
to much low level hand holding... the only thing left was c++. Then, in my 
search for the free c++ implementation that would best fit for what i wanted to 
do, i stumbled across the digital mars c++ website, and lo and behold i 
discovered the D language! :) I couldnt have found a better candidate (in my 
opinion) for what i want to do, than if someone had personally coded it for me 
and thrown it on my lap. After seeing the many incredibly smart people 
interested in D, and walters dedication to making it work (and proven 
experience), i think ive found a home... Not only has a second language but as 
good tool for what i want to do otherwise...

So with all this in mind, please feel free to correct me (or enlighten) anytime 
i make incorrect assumptions about how things work in D (or C/C++ type 
languages), I feel i am a fast learner but i always appreciate help, and give 
any in return if possible. And also keep in mind that im always for anything 
that will make it "easier" to do something in the language, however i realize 
that alot of times its an unneccasary syntax that could be easily done from a 
library or header...

So anyway, back to COM and ease of use... ;)
In vb6 everything under the hood object wise is COM or forced to act like COM.
In vb when i dimension an object variable, it is simply that, a object
reference 
variable to nothing, equalling 0... Then we bind a "com" object to it with two 
different methods, called late-binding and early-binding, late binding is where 
the interface to the object is not known until runtime and is done with the 
CreateObject() function. this is also commonly done from scripts like asp and 
vbscript... and example Code syntax might be something like:

int getAge() {
// create the late bound object variable
  interface foo;
// assign it to a COM object interface with late binding, through the com 
object's known progid
  interface foo = CreateObject("ComObject.Interface");
  //you can now (indirectly) call foo's methods
    int bar = 20;
    return foo.CalculateAge(bar);
    //delete the object?
    foo = null;
}

however if you know anything about com you know that you've violated alot of 
rules in the above code, mainly you didnt call AddRef() or Release() to change 
the ref count that the object has to do in itself... this is how vb spoils
there 
programmers by doing all that under the hood... Also the line to delete the 
object is unnessacary because vb calls Release() and deletes the object
variable 
(cleans it up) as soon as it goes out of the scope of the function (or you can 
do it yourself if you wish)...
Im not sure how D handles things like this yet with scope cleanup and garbage 
collection...
Theres a few latebinding functions you can use that are basically wrappers for
a 
few api calls.
CreateObject(ProgID),GetObject(Filename),GetObject(filename, ProgID), 
GetObject(ProgID)

One big problem with late-binding is speed, it is slow because you have to go 
thru the IDispatch interface with each call to "resolve" function and property 
names...

With vb we can with a few clicks create a reference to a component and it will 
build a "type library" automatically and bind to an interface of your choosing 
within the component, all automatically, creating a compile time (design-time
in 
vb) reference to every public method and property in the interface. Example
code 
from a vb perspective might look like so...

int GetAge() {

  COMObject foo;
  foo = new COMObject;

   //some method of resolving the com object from a guid
   foo = resolveobjectfromid(clsid);

//assume we have an interface defined somewhere already
  interface bar;

//compatible with foo object's SomeInterface)
  bar = new SomeInterface;

  //bind it to foo's SomeInterface
  bar = bind(foo.SomeInterface);

  //now we can directly call bar's methods because we are bound to the vtable
of 
foo's bar interface
  return bar.CalculateAge(20);

  //delete bar and foo
  bar = null;
  foo = null;

}

Some things to note, in vb it would be unnessacary to create the foo Object, 
because it is alive for the entire lifetime of the project through a reference, 
so technically foo is an already known reference that you can just:
  bar = bind(foo.SomeInterface);
without creating the foo object. but for clarity here i added it in.

I guess im not suggesting that all these methods are added in the D language 
intrinsically itself...
But what i am saying is since that all COM objects have several redundant 
methods that must be called for each item you create, Specifically AddRef() and 
Release() and all interfaces and objects inherit from IUnknown... it would be 
nice if the compiler kept track of scope and did ref counting automatically, 
this would remove the need for some redundant code and take some unnessacary 
burden off the programmer...

So what basically would then happen in the above code is this:

int GetAge() {

  Component foo; //addref is not called, its only an empty place holder variable
  foo = new Component; //addref is still not called, its only a template for a 
component

//or alternatively: Component foo = new Component;

   //some method of resolving the com object from a clsid
   foo = foo.resolve(clsid); //addref is called, we have created the object

//assume we have an interface defined somewhere already
  interface bar; //addref is not called, its only a variable

//compatible with foo object's SomeInterface)
  bar = new SomeInterface; //addref is still not called, its only a template
for bar

  //bind it to foo's SomeInterface
  bar = foo.bind(foo.SomeInterface); //addref is called, weve created the
interface

//or alternatively: bar = bar.bind(foo.SomeInterface); //addref auto called

  //now we can directly call bar's methods because we are bound to the vtable
of 
foo's bar interface
  int Decay = 20;
  return bar.CalculateAge(&Decay);

  //delete bar and foo
  bar = null; //Release() is called to de-increment refcount,and reference 
variable destoyed
  foo = null; //same

//or alternatively, compiler realizes scope is gone and implicitly calls 
release(), and destroys both object variables which removes the need to set 
variables to null

}

In the above scenario the built in COM Object would have subjectivly two
methods 
for early binding , resolve(clsid) and bind(reference to interface), and also 
perhaps a destroy() method for explicit deletion...

Now that ive shown how much im spoiled by vb :) i would love to hear if any of 
these ideas are viable or if they should be done outside of D (such as in a 
library or code)

regards
Lewis
Dec 16 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Awesome!

I myself have found that trying to implement a COM wrapper is one of the
things that makes me glad C++ has mixins.  Unfortunately C++ mixin support
is not that much of a help as it brings along several problems of its own.

Moving this grunt work into the compiler would be one solution, but
enhancing the language to the point where something like a COM smart pointer
become possible, and easy to put in a library, would be much better.

Sean

"Lewis" <dethbomb hotmail.com> wrote in message
news:broj4i$jtk$1 digitaldaemon.com...

 Let me start by first clarifing where i come from, and why i say some of


the

 things i do (albeit probably ignorantly in context to D most of the time)
 Ive only ever programmed in visual basic and for windows. In the vb


community im

 known as one of those "optimizer freaks" that is never happy with the fact


that

 code works. It must work extremely well, as fast as is possible using any


api or

 assembly hack we can find or write, and generally as error free as


possible even

 if it requires more lines of code... Between some injected assembly and


api

 useage, i can, in alot of cases create code that runs as fast (an


sometimes

 faster) than a program that does the equilavent in c++. By using assembly
 injection, I can also call C dll's from visual basic (something microsoft


will

 tell you is impossible) but...
 (speaking in general from here >)
 With us "vb freaks" its a old war to prove that vb is in fact more than a


toy

 language (and it has been proved in my opinion) and for basic gui


windows-only

 apps, i still believe its the fastest solution in most cases, but theres


several

 things that are missing from the picture...

 We often secretly admire the fact that c/c++ programs dont have a runtime


they

 have to drag along, or require the user to download a 1 mb+ runtime file


(or

 worse the .net framework) and also very few of our programs will run on
 alternate operating systems (wine still has a way to go on that) , and


visual

 basic isnt cheap, (900+ for enterprise version)...

 This along with the fact that microsoft has basically abandoned 'pure' vb
 programmers (i think few will argue that switching to vb.net from vb6 is


almost

 akin to learning a new language) and the millions of lines of COM code we


have

 now lying around... Its time to look elsewhere. Alot will probably go to


delphi

 since its the closest competitor to vb's language and rad IDE (and has


great

 support for COM), but myself i just cant do it, i decided if im going to


learn a

 new language im going to learn one that gives me the power to be flexible,


cross

 platform to an extent, and allow me to not be stuck with one technology...


Most

 of the vb programmers dont want to use delphi or c++, (they've been


enemies to

 long 'tongue in cheek'), so D offers a nice way out ;)

 When the last upgrade to the .net runtime was, once again, incompatible


with the

 first .net runtime, I decided (in a moment of disgust that involved


deleting

 .net, and mumbling anti-corporate rantings), that i was going to learn a


lower

 level language and write an interpeter for basic that supports COM


instrinsicly

 similar to visual basic. It would take my basic code with some alterations


and

 convert it to the lower level language automajically. (in other words a


BASIC

 replacement for D's frontend) This allows for several things immediately,


1) a

 promise for some portability, and 2) no required huge runtime file and 3)


easily

 do things that were hard or impossible to do in vb.

 BCX, (and Pavel Minayev's B++) have gone along way towards this goal but


both

 have very little support for COM, something i want to support in mine very


well...

 My first option of course was to furthur learn more assembly, and i


decided to

 forget that angle its just more than im willing to commit to for now, the


second

 option was C and that fell in the same catagory as assembly... it just


requires

 to much low level hand holding... the only thing left was c++. Then, in my
 search for the free c++ implementation that would best fit for what i


wanted to

 do, i stumbled across the digital mars c++ website, and lo and behold i
 discovered the D language! :) I couldnt have found a better candidate (in


my

 opinion) for what i want to do, than if someone had personally coded it


for me

 and thrown it on my lap. After seeing the many incredibly smart people
 interested in D, and walters dedication to making it work (and proven
 experience), i think ive found a home... Not only has a second language


but as

 good tool for what i want to do otherwise...

 So with all this in mind, please feel free to correct me (or enlighten)


anytime

 i make incorrect assumptions about how things work in D (or C/C++ type
 languages), I feel i am a fast learner but i always appreciate help, and


give

 any in return if possible. And also keep in mind that im always for


anything

 that will make it "easier" to do something in the language, however i


realize

 that alot of times its an unneccasary syntax that could be easily done


from a

 library or header...

 So anyway, back to COM and ease of use... ;)
 In vb6 everything under the hood object wise is COM or forced to act like


COM.

 In vb when i dimension an object variable, it is simply that, a object


reference

 variable to nothing, equalling 0... Then we bind a "com" object to it with


two

 different methods, called late-binding and early-binding, late binding is


where

 the interface to the object is not known until runtime and is done with


the

 CreateObject() function. this is also commonly done from scripts like asp


and

 vbscript... and example Code syntax might be something like:

 int getAge() {
 // create the late bound object variable
   interface foo;
 // assign it to a COM object interface with late binding, through the com
 object's known progid
   interface foo = CreateObject("ComObject.Interface");
   //you can now (indirectly) call foo's methods
     int bar = 20;
     return foo.CalculateAge(bar);
     //delete the object?
     foo = null;
 }

 however if you know anything about com you know that you've violated alot


of

 rules in the above code, mainly you didnt call AddRef() or Release() to


change

 the ref count that the object has to do in itself... this is how vb spoils


there

 programmers by doing all that under the hood... Also the line to delete


the

 object is unnessacary because vb calls Release() and deletes the object


variable

 (cleans it up) as soon as it goes out of the scope of the function (or you


can

 do it yourself if you wish)...
 Im not sure how D handles things like this yet with scope cleanup and


garbage

 collection...
 Theres a few latebinding functions you can use that are basically wrappers


for a

 few api calls.
 CreateObject(ProgID),GetObject(Filename),GetObject(filename, ProgID),
 GetObject(ProgID)

 One big problem with late-binding is speed, it is slow because you have to


go

 thru the IDispatch interface with each call to "resolve" function and


property

 names...

 With vb we can with a few clicks create a reference to a component and it


will

 build a "type library" automatically and bind to an interface of your


choosing

 within the component, all automatically, creating a compile time


(design-time in

 vb) reference to every public method and property in the interface.


Example code

 from a vb perspective might look like so...

 int GetAge() {

   COMObject foo;
   foo = new COMObject;

    //some method of resolving the com object from a guid
    foo = resolveobjectfromid(clsid);

 //assume we have an interface defined somewhere already
   interface bar;

 //compatible with foo object's SomeInterface)
   bar = new SomeInterface;

   //bind it to foo's SomeInterface
   bar = bind(foo.SomeInterface);

   //now we can directly call bar's methods because we are bound to the


vtable of

 foo's bar interface
   return bar.CalculateAge(20);

   //delete bar and foo
   bar = null;
   foo = null;

 }

 Some things to note, in vb it would be unnessacary to create the foo


Object,

 because it is alive for the entire lifetime of the project through a


reference,

 so technically foo is an already known reference that you can just:
   bar = bind(foo.SomeInterface);
 without creating the foo object. but for clarity here i added it in.

 I guess im not suggesting that all these methods are added in the D


language

 intrinsically itself...
 But what i am saying is since that all COM objects have several redundant
 methods that must be called for each item you create, Specifically


AddRef() and

 Release() and all interfaces and objects inherit from IUnknown... it would


be

 nice if the compiler kept track of scope and did ref counting


automatically,

 this would remove the need for some redundant code and take some


unnessacary

 burden off the programmer...

 So what basically would then happen in the above code is this:

 int GetAge() {

   Component foo; //addref is not called, its only an empty place holder


variable

   foo = new Component; //addref is still not called, its only a template


for a

 component

 //or alternatively: Component foo = new Component;

    //some method of resolving the com object from a clsid
    foo = foo.resolve(clsid); //addref is called, we have created the


object

 //assume we have an interface defined somewhere already
   interface bar; //addref is not called, its only a variable

 //compatible with foo object's SomeInterface)
   bar = new SomeInterface; //addref is still not called, its only a


template for bar

   //bind it to foo's SomeInterface
   bar = foo.bind(foo.SomeInterface); //addref is called, weve created the


interface

 //or alternatively: bar = bar.bind(foo.SomeInterface); //addref auto


called

   //now we can directly call bar's methods because we are bound to the


vtable of

 foo's bar interface
   int Decay = 20;
   return bar.CalculateAge(&Decay);

   //delete bar and foo
   bar = null; //Release() is called to de-increment refcount,and reference
 variable destoyed
   foo = null; //same

 //or alternatively, compiler realizes scope is gone and implicitly calls
 release(), and destroys both object variables which removes the need to


set

 variables to null

 }

 In the above scenario the built in COM Object would have subjectivly two


methods

 for early binding , resolve(clsid) and bind(reference to interface), and


also

 perhaps a destroy() method for explicit deletion...

 Now that ive shown how much im spoiled by vb :) i would love to hear if


any of

 these ideas are viable or if they should be done outside of D (such as in


a

 library or code)

 regards
 Lewis
Dec 17 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
Comments embedded.

"Lewis" <dethbomb hotmail.com> wrote in message
news:broj4i$jtk$1 digitaldaemon.com...
| ...
| We often secretly admire the fact that c/c++ programs dont have a runtime
they
| have to drag along, or require the user to download a 1 mb+ runtime file
(or
| worse the .net framework) and also very few of our programs will run on
| alternate operating systems (wine still has a way to go on that) , and
visual
| basic isnt cheap, (900+ for enterprise version)...

Those are the reasons I stepped away from vb and why I haven't entered too
much into the .net world.

|
| This along with the fact that microsoft has basically abandoned 'pure' vb
| programmers (i think few will argue that switching to vb.net from vb6 is
almost
| akin to learning a new language) and the millions of lines of COM code we
have
| now lying around... Its time to look elsewhere. Alot will probably go to
delphi
| since its the closest competitor to vb's language and rad IDE (and has
great
| support for COM), but myself i just cant do it, i decided if im going to
learn a
| new language im going to learn one that gives me the power to be flexible,
cross
| platform to an extent, and allow me to not be stuck with one technology...
Most
| of the vb programmers dont want to use delphi or c++, (they've been
enemies to
| long 'tongue in cheek'), so D offers a nice way out ;)

I'm not a big fan of the Pascal/Delphi language, but I most admit that the
Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm writing
(in Delphi 6 PE) a dll with declarations for all the GUI objects available
in Delphi, and a library (in D) calling those objects, providing a wrapper
to access them just like you would in Delphi. So far, so good. Why I'm doing
this? Because I think the way Delphi does GUI building is the best I've seen
(not that I've seen much either ;) ). If any of you is interested, let me
know and I'll keep you informed.

| ...
| BCX, (and Pavel Minayev's B++) have gone along way towards this goal but
both
| have very little support for COM, something i want to support in mine very
well...

Last time I checked, B++ hadn't been updated for a long, long while.

|
| My first option of course was to furthur learn more assembly, and i
decided to
| forget that angle its just more than im willing to commit to for now, the
second
| option was C and that fell in the same catagory as assembly... it just
requires
| to much low level hand holding... the only thing left was c++. Then, in my
| search for the free c++ implementation that would best fit for what i
wanted to
| do, i stumbled across the digital mars c++ website, and lo and behold i
| discovered the D language! :) I couldnt have found a better candidate (in
my
| opinion) for what i want to do, than if someone had personally coded it
for me
| and thrown it on my lap. After seeing the many incredibly smart people
| interested in D, and walters dedication to making it work (and proven
| experience), i think ive found a home... Not only has a second language
but as
| good tool for what i want to do otherwise...
|
| So with all this in mind, please feel free to correct me (or enlighten)
anytime
| i make incorrect assumptions about how things work in D (or C/C++ type
| languages), I feel i am a fast learner but i always appreciate help, and
give
| any in return if possible. And also keep in mind that im always for
anything
| that will make it "easier" to do something in the language, however i
realize
| that alot of times its an unneccasary syntax that could be easily done
from a
| library or header...
|
| So anyway, back to COM and ease of use... ;)
| In vb6 everything under the hood object wise is COM or forced to act like
COM.
| In vb when i dimension an object variable, it is simply that, a object
reference
| variable to nothing, equalling 0... Then we bind a "com" object to it with
two
| different methods, called late-binding and early-binding, late binding is
where
| the interface to the object is not known until runtime and is done with
the
| CreateObject() function. this is also commonly done from scripts like asp
and
| vbscript... and example Code syntax might be something like:
|
| int getAge() {
| // create the late bound object variable
|   interface foo;
| // assign it to a COM object interface with late binding, through the com
| object's known progid
|   interface foo = CreateObject("ComObject.Interface");
|   //you can now (indirectly) call foo's methods
|     int bar = 20;
|     return foo.CalculateAge(bar);
|     //delete the object?
|     foo = null;
| }

That last line won't run because return terminates the function. Also, you
don't need to free the object: the gc will do it for you.

| ...
| regards
| Lewis


-----------------------
Carlos Santander Bernal


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.552 / Virus Database: 344 - Release Date: 2003-12-15
Dec 17 2003
next sibling parent reply Walter <rickwal iinet.net.au> writes:
Carlos Santander B. wrote:
<snip>

 I'm not a big fan of the Pascal/Delphi language, but I most admit that the
 Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm writing
 (in Delphi 6 PE) a dll with declarations for all the GUI objects available
 in Delphi, and a library (in D) calling those objects, providing a wrapper
 to access them just like you would in Delphi. So far, so good. Why I'm doing
 this? Because I think the way Delphi does GUI building is the best I've seen
 (not that I've seen much either ;) ). If any of you is interested, let me
 know and I'll keep you informed.


<snip>

Hi All,
Yes please.
I use BCB 5 and am spoiled by the RAD and GUI capabilities.
The Lack of GUI capabilities and having to figure out how "make" files
work have been holding me back from D.

I have been following the newsgroup for some time and think the language 
is going to be great.

regards

Walter.
ps Hopefully I have changed the sender name to RickWal to avoid 
confusion with the real Walter.
Dec 18 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Have you tried DIDE?

There's a bunch of other tools besides make out there that you might like
better.  Make is not really evolving anymore and seems to be for old Unix
curmudgeons. I use Visual Studio (small projects... it would suck for large
D projects) and I know there are some other good make tools (listed links
below)

Ant     http://ant.apache.org/

SCons  http://www.scons.org/

Jam    http://www.perforce.com/jam/jam.html

The nice thing about tools like that is you can use them for lots of things
besides just compiling programs.

Sean

"Walter" <rickwal iinet.net.au> wrote in message
news:brrveq$2m0v$1 digitaldaemon.com...

 The Lack of GUI capabilities and having to figure out how "make" files
 work have been holding me back from D.
 Walter.
 ps Hopefully I have changed the sender name to RickWal to avoid
 confusion with the real Walter.


No, it didn't work.
Dec 18 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <rickwal iinet.net.au> wrote in message
news:brrveq$2m0v$1 digitaldaemon.com...
| Carlos Santander B. wrote:
| > (not that I've seen much either ;) ). If any of you is interested, let
me
| > know and I'll keep you informed.
|
| Hi All,
| Yes please.
| ...

Ok, then. Check http://earth.prohosting.com/carlos3, go to the delphi4d
section.

-----------------------
Carlos Santander Bernal
Dec 18 2003
parent reply Lewis <dethbomb hotmail.com> writes:
Carlos Santander B. wrote:


 "Walter" <rickwal iinet.net.au> wrote in message
 news:brrveq$2m0v$1 digitaldaemon.com...
 | Carlos Santander B. wrote:
 | > (not that I've seen much either ;) ). If any of you is interested, let
 me
 | > know and I'll keep you informed.
 |
 | Hi All,
 | Yes please.
 | ...
 
 Ok, then. Check http://earth.prohosting.com/carlos3, go to the delphi4d
 section.
 
 -----------------------
 Carlos Santander Bernal
 
 


this looks very interesting, is it possible to use this without delphi
installed?
Dec 18 2003
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Lewis" <dethbomb hotmail.com> wrote in message
news:bru9e9$627$2 digitaldaemon.com...
|
| this looks very interesting, is it possible to use this without delphi
installed?

Thanks. Yes, because Delphi programs don't need any dll to run. The only
thing needed will be the dll created with Delphi.

-----------------------
Carlos Santander Bernal
Dec 19 2003
prev sibling next sibling parent reply Ilya Minkov <midiclub tiscali.de> writes:
Hi.

I don't think VB users who hate both C++ and Delphi can be attracted to 
D. It's just that D is much more similar to either of them than to 
Visual Basic.

Carlos Santander B. wrote:

 Last time I checked, B++ hadn't been updated for a long, long while.


I have been talking to Pavel. He plans on a new language, since he found 
severe faults in B++ design. IIRC its memory management was somewhat 
weak. The new language will be somethig like a compiled Python. I'm 
waiting for him to put up a design paper on it. Pavel himself has made 
himself comfortable with C++ (which you start to like as you get to 

really work on a new language. BCX is not even good for small projects, 
bacause its module system is not existent, and debugging is almost 
impossible.

-eye
Dec 18 2003
parent reply Lewis <dethbomb hotmail.com> writes:
Ilya Minkov wrote:


 Hi.
 
 I don't think VB users who hate both C++ and Delphi can be attracted to 
 D. It's just that D is much more similar to either of them than to 
 Visual Basic.
 
 Carlos Santander B. wrote:
 

 Last time I checked, B++ hadn't been updated for a long, long while.


 
 
 I have been talking to Pavel. He plans on a new language, since he found 
 severe faults in B++ design. IIRC its memory management was somewhat 
 weak. The new language will be somethig like a compiled Python. I'm 
 waiting for him to put up a design paper on it. Pavel himself has made 
 himself comfortable with C++ (which you start to like as you get to 

 really work on a new language. BCX is not even good for small projects, 
 bacause its module system is not existent, and debugging is almost 
 impossible.
 
 -eye
 


I really like what i saw of b++, wish pavel would have kept working on it...
but 
each to there own i guess (would love to get my hands on the source). As for 
"ael" or whatever he chose to call it, Pascal like syntax is just to weird for
me...
The nice thing about bcx is it has a nice support community, and the author is 
very helpful in fixing any bugs you find or might have.

My main goal is to write a basic like syntax front-end for D, so i only have to 
learn the D syntax to start with, not its actual semantics, then i can learn
the 
semantics later with the basic like syntax. But first im just messing around an 
experimenting with some things (playing is fun)

for example an interpeter would turn the following code:
Public MyArray(3) As String
into
public wchar[3] MyArray;
(or something similar).... and of course lots of built in macro's :)

My biggest headache is learning how librarys, headers, an such, all fit
together 
(its almost like i should learn c++ first lol)

It will take me a while (possibly years) but im fairly well set on doing 
something like this... i have little choice but to write the front end in vb to 
start with, since thats what i know inside an out at the moment.
Dec 18 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Lewis" <dethbomb hotmail.com> wrote in message
news:bru9cv$627$1 digitaldaemon.com...

 I really like what i saw of b++, wish pavel would have kept working on


it... but

 each to there own i guess (would love to get my hands on the source). As


for

 "ael" or whatever he chose to call it, Pascal like syntax is just to weird


for me...

 The nice thing about bcx is it has a nice support community, and the


author is

 very helpful in fixing any bugs you find or might have.


I haven't heard of this "b++" before, but it might be worth checking out.


 My main goal is to write a basic like syntax front-end for D, so i only


have to

 learn the D syntax to start with, not its actual semantics, then i can


learn the

 semantics later with the basic like syntax. But first im just messing


around an

 experimenting with some things (playing is fun)

 for example an interpeter would turn the following code:
 Public MyArray(3) As String
 into
 public wchar[3] MyArray;
 (or something similar).... and of course lots of built in macro's :)


My gut reaction to this is (bluntly) that it's a waste of time.  You should
dive into the native syntax right away, it'll be easier to work with that
way.  Force yourself to do the mapping to the old way of programming
mentally instead of in some tool that will probably never get finished
anyway.  The tool will quickly become a source of frustration anyway, as
things we talk about doing won't work for you because your tool doesn't
output those kinds of things properly, or it doesn't have those keywords
supported, or whatever.   Walter is constantly changing little things about
D, it's a moving target currently but that's good in a way as it's possible
a few things will be corrected before 1.0.


 My biggest headache is learning how librarys, headers, an such, all fit


together

 (its almost like i should learn c++ first lol)

 It will take me a while (possibly years) but im fairly well set on doing
 something like this... i have little choice but to write the front end in


vb to

 start with, since thats what i know inside an out at the moment.


It won't take you years to just learn D more or less "from scratch."  Just
browse on the D website thru the language docs and find some D source code
(DIG or something) and start looking thru it, start running it and then
modifying it.  Just start adding your own little functions inside of
somebody else's toy app until you start to get the hang of it.

Sean
Dec 19 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Sean L. Palmer wrote:


 My gut reaction to this is (bluntly) that it's a waste of time.  You should
 dive into the native syntax right away, it'll be easier to work with that
 way.


Sean, you're right. It may seem emotionally easier, but a syntactic 
translater, which doesn't do complete parsing and which is not 
completely debugged, is a great source of problems. It maps one source 
onto the other loosing line numbers and bending semantics, but not 
replacing it completely, and then it is impossible to debug code. Let 
Lewis give nontheless a try on this if he likes. (who knows?)


My biggest headache is learning how librarys, headers, an such, all fit
together




Hmmm... dig compiler driver (digc) might save you from grief. Modified 
version here.
http://earth.prohosting.com/carlos3/dig.htm

Lewis, you don't need to learn C++, but i would recommend you to get 
LCC-Win32 compiler and get some exposure to C. This will give you some 
knowledge of compilation model, idiotic syntax parts which are preserved 
in D, and so on. Something of the culture which (sadly) is compulsory 
for every modern programmer. While the compiler is not necessarily good 
for production work (debugger is weakish, no C++, ...), it has a neat 
and simple IDE, and - most importantly - a nice tutorial book. All is 
for free. The book gives you some simple and Windows programming, but 
doesn't take too far into the depths of C language and standard libary 
which you won't need later. So, go though the tutorials, and then switch 
happily back to D. You will really feel a great relief. After you're 
comfortable with D, you might want to learn some C++ and come back to D 
with relief and so on... ;)

In fact, i would like to recommend some book doing the same with a 
simple subset of C++ and STL, but i'm aware of none. Anyway, Bjarne 
Stroustrup has been considering modern C++ as a better language for 
beginners than C. I would argue that C++ is better than C for any 
serious project, even if for beginners, but not necessarily as the first 
language to start experimenting with. Anyway, D is *much* better than 
either by itself, and were a *perfect* language for beginning 
programmers if the library and tools were comprehensive. I bet and wish 
we will arrive there someday...

-eye
Dec 19 2003
next sibling parent reply Lewis <dethbomb hotmail.com> writes:
thanks for all the tips Ilya... I already have lcc-win32 along with half a
dozen 
other compilers. In fact if theres a free compiler C\C++ out there i probably 
have it lol...

The problem is i also have so many "librarys", header files, and stuff thats
its 
getting confusing. How does one know which library and headers are the best to 
use and where to put them all, and when to use what...

Lots of things have yet to make sense to me, such as why are there 'typedef's' 
and alias this and that... i see alot of data types that are simply duplicates 
of an existing type, which makes no sense to me except cause confusion, why not 
use the original datatype to start with?

Any how as i ponder these mysteries....


Ilya Minkov wrote:

 Sean L. Palmer wrote:
 

 My gut reaction to this is (bluntly) that it's a waste of time.  You 
 should
 dive into the native syntax right away, it'll be easier to work with that
 way.


 
 
 Sean, you're right. It may seem emotionally easier, but a syntactic 
 translater, which doesn't do complete parsing and which is not 
 completely debugged, is a great source of problems. It maps one source 
 onto the other loosing line numbers and bending semantics, but not 
 replacing it completely, and then it is impossible to debug code. Let 
 Lewis give nontheless a try on this if he likes. (who knows?)
 

 My biggest headache is learning how librarys, headers, an such, all fit
 together




 
 
 Hmmm... dig compiler driver (digc) might save you from grief. Modified 
 version here.
 http://earth.prohosting.com/carlos3/dig.htm
 
 Lewis, you don't need to learn C++, but i would recommend you to get 
 LCC-Win32 compiler and get some exposure to C. This will give you some 
 knowledge of compilation model, idiotic syntax parts which are preserved 
 in D, and so on. Something of the culture which (sadly) is compulsory 
 for every modern programmer. While the compiler is not necessarily good 
 for production work (debugger is weakish, no C++, ...), it has a neat 
 and simple IDE, and - most importantly - a nice tutorial book. All is 
 for free. The book gives you some simple and Windows programming, but 
 doesn't take too far into the depths of C language and standard libary 
 which you won't need later. So, go though the tutorials, and then switch 
 happily back to D. You will really feel a great relief. After you're 
 comfortable with D, you might want to learn some C++ and come back to D 
 with relief and so on... ;)
 
 In fact, i would like to recommend some book doing the same with a 
 simple subset of C++ and STL, but i'm aware of none. Anyway, Bjarne 
 Stroustrup has been considering modern C++ as a better language for 
 beginners than C. I would argue that C++ is better than C for any 
 serious project, even if for beginners, but not necessarily as the first 
 language to start experimenting with. Anyway, D is *much* better than 
 either by itself, and were a *perfect* language for beginning 
 programmers if the library and tools were comprehensive. I bet and wish 
 we will arrive there someday...
 
 -eye
Dec 19 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Lewis wrote:

 thanks for all the tips Ilya... I already have lcc-win32 along with half 
 a dozen other compilers. In fact if theres a free compiler C\C++ out 
 there i probably have it lol...
 
 The problem is i also have so many "librarys", header files, and stuff 
 thats its getting confusing. How does one know which library and headers 
 are the best to use and where to put them all, and when to use what...
 
 Lots of things have yet to make sense to me, such as why are there 
 'typedef's' and alias this and that... i see alot of data types that are 
 simply duplicates of an existing type, which makes no sense to me except 
 cause confusion, why not use the original datatype to start with?
 
 Any how as i ponder these mysteries....


I come from a strong BASIC background (QBASIC, VB, and BCX in 
particular), so I think I can appreciate some of your concern about 
learning D. I've worked some on a tutorial that kind of teaches D from a 
BASIC perspective (http://jcc_7.tripod.com/d/tutor/), but I haven't put 
too much work into it yet, so it's pretty short.

I've found that the best way to learn D is to code in D. (Imagine that!) 
When I start learning a new language, I generally begin by porting the 
kind of programs I like to write. So one thing that I've done to learn D 
is to take a simple BCX sample program (many are available at 
http://groups.yahoo.com/group/BCX/) and port either the .bas file or the 
translated .c file into D. It can work out pretty well. But the best 
thing is probably to look at D code.  There's more and more of it out there.

Unfortunately since the language itself is still in flux, bit-rot can 
occur pretty quickly. Code that ran perfectly a couple months ago tends 
to require a few modifications to compile today. Making the required 
changed is not necessarily a problem for someone who's been around here 
for a while, but it can be frustrating for newcomers.

So if you come up with a question, ask away. It's likely that someone 
here has already confronted a similar issue.

Back to the original topic of COM...
Using COM isn't transparent in D (at least not yet) as it can be in VB, 
but it will become easier to use as the D libraries catch up.  I've got 
an idea to use COM in a VBish way that seems to work in BCX that I hope 
to port to D in the next month or so, but it may not pan out.  And it 
really is a kind of hack anyway. I'll announce it here if I get it to 
work at all.

-- 
Justin
http://jcc_7.tripod.com/d/
Dec 19 2003
parent reply Lewis <dethbomb hotmail.com> writes:
J C Calvarese wrote:

 Lewis wrote:
 

 thanks for all the tips Ilya... I already have lcc-win32 along with 
 half a dozen other compilers. In fact if theres a free compiler C\C++ 
 out there i probably have it lol...

 The problem is i also have so many "librarys", header files, and stuff 
 thats its getting confusing. How does one know which library and 
 headers are the best to use and where to put them all, and when to use 
 what...

 Lots of things have yet to make sense to me, such as why are there 
 'typedef's' and alias this and that... i see alot of data types that 
 are simply duplicates of an existing type, which makes no sense to me 
 except cause confusion, why not use the original datatype to start with?

 Any how as i ponder these mysteries....


 
 
 I come from a strong BASIC background (QBASIC, VB, and BCX in 
 particular), so I think I can appreciate some of your concern about 
 learning D. I've worked some on a tutorial that kind of teaches D from a 
 BASIC perspective (http://jcc_7.tripod.com/d/tutor/), but I haven't put 
 too much work into it yet, so it's pretty short.
 
 I've found that the best way to learn D is to code in D. (Imagine that!) 
 When I start learning a new language, I generally begin by porting the 
 kind of programs I like to write. So one thing that I've done to learn D 
 is to take a simple BCX sample program (many are available at 
 http://groups.yahoo.com/group/BCX/) and port either the .bas file or the 
 translated .c file into D. It can work out pretty well. But the best 
 thing is probably to look at D code.  There's more and more of it out 
 there.
 
 Unfortunately since the language itself is still in flux, bit-rot can 
 occur pretty quickly. Code that ran perfectly a couple months ago tends 
 to require a few modifications to compile today. Making the required 
 changed is not necessarily a problem for someone who's been around here 
 for a while, but it can be frustrating for newcomers.
 
 So if you come up with a question, ask away. It's likely that someone 
 here has already confronted a similar issue.
 
 Back to the original topic of COM...
 Using COM isn't transparent in D (at least not yet) as it can be in VB, 
 but it will become easier to use as the D libraries catch up.  I've got 
 an idea to use COM in a VBish way that seems to work in BCX that I hope 
 to port to D in the next month or so, but it may not pan out.  And it 
 really is a kind of hack anyway. I'll announce it here if I get it to 
 work at all.
 


very helpful tutorial JC thanks for the link! One thing that bugs me is using 
printf() on my computer for some reason the window closes right away, many
times 
flashes so fast i dont get a chance to even read what it said  :(
Is there a way to stop it from closing? in vb i can use the ReadConsole() api
to 
keep it from closing, but i havent found the equilevant in D ...
Dec 20 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Lewis wrote:

 
 very helpful tutorial JC thanks for the link! One thing that bugs me is 
 using printf() on my computer for some reason the window closes right 
 away, many times flashes so fast i dont get a chance to even read what 
 it said  :(
 Is there a way to stop it from closing? in vb i can use the 
 ReadConsole() api to keep it from closing, but i havent found the 
 equilevant in D ...


I usually write simple batch files to compile my programs that usually 
look like this:

 echo off
dmd myprog.d
myprog.exe
pause

The pause at the end does the trick for me.


I've tried to use scanf to get a similar result within a program before, 
but it always seems to demand that I type something in before I press 
enter (and half the time it gives me an "Access Violation").

But I just found a way to embed the pause in the program:

--------------------------------------------
extern (C) int system (char *);
void main()
{
	printf("Some text\n\0");
	system("pause");
	printf("And finally this\n\0");
	system("pause");
}
--------------------------------------------

I think this will help you out.


-- 
Justin
http://jcc_7.tripod.com/d/
Dec 20 2003
next sibling parent reply "C. Sauls" <ibisbasenji yahoo.com> writes:
J C Calvarese wrote:


 Lewis wrote:
 

 very helpful tutorial JC thanks for the link! One thing that bugs me 
 is using printf() on my computer for some reason the window closes 
 right away, many times flashes so fast i dont get a chance to even 
 read what it said  :(
 Is there a way to stop it from closing? in vb i can use the 
 ReadConsole() api to keep it from closing, but i havent found the 
 equilevant in D ...


 
 
 I usually write simple batch files to compile my programs that usually 
 look like this:
 
  echo off
 dmd myprog.d
 myprog.exe
 pause
 
 The pause at the end does the trick for me.
 
 
 I've tried to use scanf to get a similar result within a program before, 
 but it always seems to demand that I type something in before I press 
 enter (and half the time it gives me an "Access Violation").
 
 But I just found a way to embed the pause in the program:
 
 --------------------------------------------
 extern (C) int system (char *);
 void main()
 {
     printf("Some text\n\0");
     system("pause");
     printf("And finally this\n\0");
     system("pause");
 }
 --------------------------------------------
 
 I think this will help you out.
 
 


If you're importing std.c.stdio and using the printf() there, you can 
call getch() to wait for any keyboard input.  Or if you're using 
std.stream then use stdin.getch() which does.... well the same thing. 
I've stuck a getch() temporarily near the close of many a program, I 
know how it is.

  -- C. Sauls
  -- Invironz
Dec 20 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
You'd think Visual Studio would have an option to pipe stdout into a log
somewhere, but it doesn't.

Sean

"C. Sauls" <ibisbasenji yahoo.com> wrote in message
news:bs2evq$hde$2 digitaldaemon.com...

 If you're importing std.c.stdio and using the printf() there, you can
 call getch() to wait for any keyboard input.  Or if you're using
 std.stream then use stdin.getch() which does.... well the same thing.
 I've stuck a getch() temporarily near the close of many a program, I
 know how it is.
Dec 20 2003
prev sibling parent Lewis <dethbomb hotmail.com> writes:
C. Sauls wrote:

 J C Calvarese wrote:
 

 Lewis wrote:


 very helpful tutorial JC thanks for the link! One thing that bugs me 
 is using printf() on my computer for some reason the window closes 
 right away, many times flashes so fast i dont get a chance to even 
 read what it said  :(
 Is there a way to stop it from closing? in vb i can use the 
 ReadConsole() api to keep it from closing, but i havent found the 
 equilevant in D ...




 I usually write simple batch files to compile my programs that usually 
 look like this:

  echo off
 dmd myprog.d
 myprog.exe
 pause

 The pause at the end does the trick for me.


 I've tried to use scanf to get a similar result within a program 
 before, but it always seems to demand that I type something in before 
 I press enter (and half the time it gives me an "Access Violation").

 But I just found a way to embed the pause in the program:

 --------------------------------------------
 extern (C) int system (char *);
 void main()
 {
     printf("Some text\n\0");
     system("pause");
     printf("And finally this\n\0");
     system("pause");
 }
 --------------------------------------------

 I think this will help you out.


 
 If you're importing std.c.stdio and using the printf() there, you can 
 call getch() to wait for any keyboard input.  Or if you're using 
 std.stream then use stdin.getch() which does.... well the same thing. 
 I've stuck a getch() temporarily near the close of many a program, I 
 know how it is.
 
  -- C. Sauls
  -- Invironz
 


yes, thats does the trick nicely, also seems getchar() works too... thanks
Dec 20 2003
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
  echo off
 dmd myprog.d
 myprog.exe
 pause


Try

  echo off
 dmd myprog.d &&  myprog.exe
 pause

for a simple make-like behaviour. :)

Matthew
Dec 21 2003
parent J C Calvarese <jcc7 cox.net> writes:
Matthew wrote:

 echo off
dmd myprog.d
myprog.exe
pause


 
 
 Try
 
   echo off
  dmd myprog.d &&  myprog.exe
  pause


Now that's a cool trick.

(I'm glad Lewis asked this question.  I'm learning all kinds of things 
from it.)


 
 for a simple make-like behaviour. :)
 
 Matthew
 
 



-- 
Justin
http://jcc_7.tripod.com/d/
Dec 21 2003
prev sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <brvelu$1umc$1 digitaldaemon.com>, Ilya Minkov wrote:

My biggest headache is learning how librarys, headers, an such, all fit
together




 
 Lewis, you don't need to learn C++, but i would recommend you to get 
 LCC-Win32 compiler and get some exposure to C. This will give you some 
 knowledge of compilation model, idiotic syntax parts which are preserved 
 in D, and so on. Something of the culture which (sadly) is compulsory 
 for every modern programmer. While the compiler is not necessarily good 
 for production work (debugger is weakish, no C++, ...), it has a neat 
 and simple IDE, and - most importantly - a nice tutorial book. All is 
 for free. The book gives you some simple and Windows programming, but 
 doesn't take too far into the depths of C language and standard libary 
 which you won't need later. So, go though the tutorials, and then switch 
 happily back to D. You will really feel a great relief. After you're 
 comfortable with D, you might want to learn some C++ and come back to D 
 with relief and so on... ;)
 
 In fact, i would like to recommend some book doing the same with a 
 simple subset of C++ and STL, but i'm aware of none. Anyway, Bjarne 
 Stroustrup has been considering modern C++ as a better language for 
 beginners than C.


They say that Accelerated C++ (Koenig & Moo 2000,
http://www.acceleratedcpp.com/) is a really good book. I've only shortly
browsed through it myself, but you check out for example Francis
Glassborow's review for more praise.  (Link can be found from the book's
web site.)

In short, the book is supposed to introduce the most useful C++ concepts
without overwhelming the beginner with details inherited from C.

-Antti
Dec 27 2003
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:brqk6e$l3k$1 digitaldaemon.com...
|
| I'm not a big fan of the Pascal/Delphi language, but I most admit that the
| Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm
writing
| (in Delphi 6 PE) a dll with declarations for all the GUI objects available
| in Delphi, and a library (in D) calling those objects, providing a wrapper
| to access them just like you would in Delphi. So far, so good. Why I'm
doing
| this? Because I think the way Delphi does GUI building is the best I've
seen
| (not that I've seen much either ;) ). If any of you is interested, let me
| know and I'll keep you informed.
|

I kinda need some help here.
Let's say I don't want to create a dll from Delphi, but rather an obj and
use it directly for the D library. Right now, when I try it, the linker
complies about not finding *any* of the functions created with Delphi. All I
can think of is that there's some incompatibility between the object files.
Is there a way to make this work?

-----------------------
Carlos Santander Bernal
Dec 19 2003
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bs0he3$itp$1 digitaldaemon.com...
|
| I kinda need some help here.
| Let's say I don't want to create a dll from Delphi, but rather an obj and
| use it directly for the D library. Right now, when I try it, the linker
| complies about not finding *any* of the functions created with Delphi. All
I
| can think of is that there's some incompatibility between the object
files.
| Is there a way to make this work?
|

(Forgot to mention: C obj)
Interestingly, Microsoft linker can convert DM's obj, but can't convert
Borland's. Is that well known? Is there a converter or something?

-----------------------
Carlos Santander Bernal
Dec 19 2003
parent J C Calvarese <jcc7 cox.net> writes:
Carlos Santander B. wrote:

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:bs0he3$itp$1 digitaldaemon.com...
 |
 | I kinda need some help here.
 | Let's say I don't want to create a dll from Delphi, but rather an obj and
 | use it directly for the D library. Right now, when I try it, the linker
 | complies about not finding *any* of the functions created with Delphi. All
 I
 | can think of is that there's some incompatibility between the object
 files.
 | Is there a way to make this work?
 |
 
 (Forgot to mention: C obj)
 Interestingly, Microsoft linker can convert DM's obj, but can't convert
 Borland's. Is that well known? Is there a converter or something?


I don't really any more than what I read (skimmed, really) here:
http://www.digitalmars.com/ctg/implib.html#coff2omf
http://www.faqs.org/faqs/msdos-programmer-faq/part2/section-7.html
http://www.mega-tokyo.com/os/os-faq-linker.html
http://www.bcbdev.com/faqs/faq92.htm

Microsoft is COFF.
Digital Mars is Intel 32 bit OMF.
Borland is either? both?

(I'd better send this message before I add any more URLs.)

Good luck.


 
 -----------------------
 Carlos Santander Bernal
Dec 19 2003
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:brqk6e$l3k$1 digitaldaemon.com...
|
| I'm not a big fan of the Pascal/Delphi language, but I most admit that the
| Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm
writing
| (in Delphi 6 PE) a dll with declarations for all the GUI objects available
| in Delphi, and a library (in D) calling those objects, providing a wrapper
| to access them just like you would in Delphi. So far, so good. Why I'm
doing
| this? Because I think the way Delphi does GUI building is the best I've
seen
| (not that I've seen much either ;) ). If any of you is interested, let me
| know and I'll keep you informed.
|

Another question regarding the same. How can I know for sure if I'm not
releasing/freeing/deleting every object in Delphi? I know D objects are
collected by the GC, but what about Delphi? Does it do the same? I try to
call Free for every object I create, but I just wanna be sure.

-----------------------
Carlos Santander Bernal
Dec 20 2003
next sibling parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
Delphi doesn't have automatic memory allocation/deallocation except for
TString objects wich are reference counted. So yes, you have to call Free to
release any object.


Carlos Santander B. <carlos8294 msn.com> escribió en el mensaje de noticias
bs3029$1cu8$1 digitaldaemon.com...

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:brqk6e$l3k$1 digitaldaemon.com...
 |
 | I'm not a big fan of the Pascal/Delphi language, but I most admit that


the

 | Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm
 writing
 | (in Delphi 6 PE) a dll with declarations for all the GUI objects


available

 | in Delphi, and a library (in D) calling those objects, providing a


wrapper

 | to access them just like you would in Delphi. So far, so good. Why I'm
 doing
 | this? Because I think the way Delphi does GUI building is the best I've
 seen
 | (not that I've seen much either ;) ). If any of you is interested, let


me

 | know and I'll keep you informed.
 |

 Another question regarding the same. How can I know for sure if I'm not
 releasing/freeing/deleting every object in Delphi? I know D objects are
 collected by the GC, but what about Delphi? Does it do the same? I try to
 call Free for every object I create, but I just wanna be sure.

 -----------------------
 Carlos Santander Bernal
Dec 20 2003
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <bs3029$1cu8$1 digitaldaemon.com>, Carlos Santander B. says...

"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:brqk6e$l3k$1 digitaldaemon.com...
|
| I'm not a big fan of the Pascal/Delphi language, but I most admit that the
| Delphi/Kylix environment/tool/rad is great. As a matter of fact, I'm
writing
| (in Delphi 6 PE) a dll with declarations for all the GUI objects available
| in Delphi, and a library (in D) calling those objects, providing a wrapper
| to access them just like you would in Delphi. So far, so good. Why I'm
doing
| this? Because I think the way Delphi does GUI building is the best I've
seen
| (not that I've seen much either ;) ). If any of you is interested, let me
| know and I'll keep you informed.
|


So you build the GUI using Delphi and then use your library DLL to interface
them?  Maybe you could put a more complete step by step example on your web
site. 

I've done similar things with VB and C for quick and dirty apps. Use the GUI
building tool for the user interface part and do the all the rest in a more
portable language (and one that I know). It was a lot quicker than doing MFC. It
also forces you to decouple the user interface layer from the domain layer which
is a good design practice.

Mark
Dec 23 2003
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Mark T" <Mark_member pathlink.com> wrote in message
news:bs9mls$1as2$1 digitaldaemon.com...
|
| So you build the GUI using Delphi and then use your library DLL to
interface
| them?  Maybe you could put a more complete step by step example on your
web
| site.
|
| I've done similar things with VB and C for quick and dirty apps. Use the
GUI
| building tool for the user interface part and do the all the rest in a
more
| portable language (and one that I know). It was a lot quicker than doing
MFC. It
| also forces you to decouple the user interface layer from the domain layer
which
| is a good design practice.
|
| Mark
|
|

Not really. Let me show by example.
In Delphi you define windows by inheriting from TForm. What I'm doing is
defining a TForm in D, which has a reference to a Delphi TForm. So, if you
do this in D:
class MyForm : TForm { ... }
...
(new MyForm).ShowModal();
In the constructor of TForm, there's a call to initialize a new TForm from
Delphi, and save it in a void *. Calls like ShowModal are then passed to
this member, which is a Delphi object.
I'm not good at explaining. I've uploaded what I've done so far (not
much, btw) so you can judge by yourself. Especially, I'd like to hear
comments about the way events are handled. I've also set up
http://s3.invisionfree.com/ln5yrestgv/index.php?act=idx, a forum to discuss
about anything D related, including Delphi4D. You have to register to access
it, but I'm gonna try to change that. Anyway, express yourself there.

-----------------------
Carlos Santander Bernal
Dec 28 2003
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bsn69m$23p9$1 digitaldaemon.com...
| comments about the way events are handled. I've also set up
| http://s3.invisionfree.com/ln5yrestgv/index.php?act=idx, a forum to
discuss
| about anything D related, including Delphi4D. You have to register to
access
| it, but I'm gonna try to change that. Anyway, express yourself there.
|

Ok, no need to register to read, but if you want to post, you need to set up
an account.

-----------------------
Carlos Santander Bernal
Dec 28 2003