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

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

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

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

 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

 that the garbage collector doesnt interfere with its reference counting,

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

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

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

 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

 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

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

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

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

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

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

 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

 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

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

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

 things that are missing from the picture...

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

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

 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

 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

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

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

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

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

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

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

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

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

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

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

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

 level language and write an interpeter for basic that supports COM

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

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

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

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

 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

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

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

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

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

 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

 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

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

 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

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

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

 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

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

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

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

 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

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

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

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

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

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

 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

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

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

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

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

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

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

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

 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

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

 names...

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

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

 within the component, all automatically, creating a compile time

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

 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

 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

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

 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

 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

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

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

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

 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

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

 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

 //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

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

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

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

 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

 variables to null

 }

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

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

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

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

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

 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.

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 understand it) and with C#. This makes it even less probable for him 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 understand it) and with C#. This makes it even less probable for him 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

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

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

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

 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

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

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

 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

 (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

 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

 | 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

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

 | 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

 | 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