Board index » delphi » migrate VB >> Delphi

migrate VB >> Delphi

Hi,

I'm searching for a solution to migrate a VB Project to a Delphi Project.
Does anyone know a good tool to convert the VB forms to Delphi's .dfm-files?
So I can save some time... it's really important for me to convert the (107)
forms to dfm's.

Thanks ans good night,
    arnd, tired.

 

Re:migrate VB >> Delphi


Re:migrate VB >> Delphi


You could try a piece of software called "Delux". You can find more
information at www.deluxsoftware.co.uk. Unfortunately, it's quite
expensive, and the standard edition won't convert database code. It's not
perfect, but it can do a good job of some things.
Quote
Arnd Issler wrote:
> Hi,
> I'm searching for a solution to migrate a VB Project to a Delphi Project.
> Does anyone know a good tool to convert the VB forms to Delphi's .dfm-files?
> So I can save some time... it's really important for me to convert the (107)
> forms to dfm's.
> Thanks ans good night,
>     arnd, tired.

Re:migrate VB >> Delphi


Re:migrate VB >> Delphi


Quote
Arnd Issler wrote:
> I'm searching for a solution to migrate a VB Project to a Delphi Project.
> Does anyone know a good tool to convert the VB forms to Delphi's
> .dfm-files? So I can save some time... it's really important for me to
> convert the (107) forms to dfm's.

In my experience, most programs "die in the clothes they wuz burn'd [born]
in."  They are not [successfully] converted from one language to another.

VB now has a halfway-respectable compiler.  If you can identify the exact
reasons that prompt you to change languages, you can probably devise an
acceptable solution that doesn't require that.

----------------------------------
Fast automatic table repair at a click of a mouse!
http://www.sundialservices.com/products/chimneysweep

Re:migrate VB >> Delphi


On Mon, 19 May 2003 09:15:37 -0700, Sundial Services

Quote
<info_...@sundialservices.com> wrote:

<snip>

Quote
>VB now has a halfway-respectable compiler.  If you can identify the exact
>reasons that prompt you to change languages, you can probably devise an
>acceptable solution that doesn't require that.

I think what Sundial is saying is that you can produce a 'hybrid' with
far less effort (and risk)

Personally I would be far less charitable :-

If you have 170 'designed' Forms then there is something wrong

You should have one (or maybe two) base Forms
- and a sodding great INI file that 'creates' everything else

Translation/porting would then be relatively easy

My solution would be to sort out the VB first

- being in favour (sometimes) of 'de-normalized' data
  -  'de-normalized' Code is ... well blubber

Re:migrate VB >> Delphi


Quote
"J French" <Bounce_It_je...@iss.u-net.com_.bin> wrote in message

news:3ec9104e.36830248@news.btclick.com...

Quote
> On Mon, 19 May 2003 09:15:37 -0700, Sundial Services
> <info_...@sundialservices.com> wrote:

> <snip>
> >VB now has a halfway-respectable compiler.  If you can identify the exact
> >reasons that prompt you to change languages, you can probably devise an
> >acceptable solution that doesn't require that.

> I think what Sundial is saying is that you can produce a 'hybrid' with
> far less effort (and risk)

> Personally I would be far less charitable :-

> If you have 170

(107 according to the OP)

Quote
> 'designed' Forms then there is something wrong

> You should have one (or maybe two) base Forms
> - and a sodding great INI file that 'creates' everything else

> Translation/porting would then be relatively easy

> My solution would be to sort out the VB first

> - being in favour (sometimes) of 'de-normalized' data
>   -  'de-normalized' Code is ... well blubber

I think a better metric would be the forms:lines-of-productive-code. For
example, a huge, complex, port simulator that I wrote had on the order of
100 forms (with enough components and other cruft to blow up the Win95
resource handling if you had them all open at the same time). There was no
real way that this could be made into an ini file due to the complex form of
the information, and how it was all interlinked. IIRC the source code alone,
excluding resources, was upwards of 3MB. In this case, I think 10 forms
would be OK.

However, if you have 100 forms, and maybe only 1000 lines of productive
code, I would agree that there is something wrong ...

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :)
Add michael@ to emboss.co.nz - My inbox is always open

Re:migrate VB >> Delphi


On Tue, 20 May 2003 18:55:23 +1200, "Michael Brown"
Quote
<s...@signature.below> wrote:

<snip>

Quote
>However, if you have 100 forms, and maybe only 1000 lines of productive
>code, I would agree that there is something wrong ...

Agreed, there are exceptions to every rule

? is there an exception to that rule ??

However the 107 does sound a bit excessive ...

Re:migrate VB >> Delphi


Quote
> However the 107 does sound a bit excessive ...

Hm, okay, so you want to create all the forms during run-time? And when, why
and how?

Let me explain, why I create 107(!) designed forms:
My app is an aplication for a small company for managing their sales, bills,
contacts, workers, etc. I designed many forms for search queries, input data
and so on. Why I should do this dynamic?

Please excuse my bad english, it's too late for answering postings...
Good night then,
    ai, anxious to see your answers.

Re:migrate VB >> Delphi


"Arnd Issler" <meistergrill2...@gmx.de> skrev i melding
news:baefbg$efj$1@nets3.rz.RWTH-Aachen.DE...

Quote
> > However the 107 does sound a bit excessive ...

> Hm, okay, so you want to create all the forms during run-time? And when,
why
> and how?

> Let me explain, why I create 107(!) designed forms:
> My app is an aplication for a small company for managing their sales,
bills,
> contacts, workers, etc. I designed many forms for search queries, input
data
> and so on. Why I should do this dynamic?

First, let me say that I have no opinion whether your 107 forms is a result
of good or poor design.

CON: A developer's nightmare. How on earth do you get the overall picture
within reasonable time ? How can you ever be sure you have updated all
affected components once the database is modified ? Who's gonna pay for you
designing all them forms ? If you want to alter something that affects more
forms, you have to do it ...more times.

PRO: It's hard to do accurate and delicate design without actually having
the form in front of you. A good example is the 'SQL Explorer' provided with
Delphi. All screen elements are formatted in a generalized manner, resulting
in an extremely innefficient GUI. But from an OO programmer's point of view,
it's elegant ;-) Hah, Jerry, I believe that one hit you below your belt !
;-)

Quote
> Please excuse my bad english, it's too late for answering postings...
> Good night then,
>     ai, anxious to see your answers.

I've been working on an administrative application with some 30 forms or so.
The number of forms has been fairly stable, but I've worked hard to move
*functionality* from the forms into generalized units. This is probably the
worst possible scenario: 107 forms loaded with buttonclick handlers
containing code filled in with copy'n paste. Now, if there is one issue to
be solved when migrating, it has to be repeated for every similar code
piece. High level of generalization simplifies such modifications
dramatically.

--
Regards,

Bj?rge S?ther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.

Re:migrate VB >> Delphi


On Wed, 21 May 2003 01:56:38 +0200, "Arnd Issler"

Quote
<meistergrill2...@gmx.de> wrote:
>> However the 107 does sound a bit excessive ...

>Hm, okay, so you want to create all the forms during run-time? And when, why
>and how?

>Let me explain, why I create 107(!) designed forms:
>My app is an aplication for a small company for managing their sales, bills,
>contacts, workers, etc. I designed many forms for search queries, input data
>and so on. Why I should do this dynamic?

Bj?rge's answer covers most of it

From a different angle :

Both Delphi .DFM and a VB .FRM files are actually parameter files

When you design a Form you are using a Visual utility to manipulate
the parameters.

Nothing wrong with that

However, the code you write sits in a .PAS unit or in VB the lower bit
of the .FRM file

Within even one VB Form a heck of a lot of code is simply duplicated
- unless you rip it out and put it in a UserControl
- ditto with Delphi

Once you start doing that, you land up with a relatively small number
of Visual Objects.

I assume that with VB you make extensive use of Control Arrays, and
that you have found it far easier to Load and position them on the
Form 'on the fly'

The next step from having stuff positioned on the fly is to remove the
parameters from the Form and put them in a parameter file of your own.

The advantage of this is that you land up with (say) just one 'general
purpose' Form that does very little, but displays and 'controls' a
number of very heavily re-used components.

Code re-use is something to aim for in its own right
- for a start it tends to make bugs reveal themselves
- also it makes general modifications much easier

Pushing stuff into 'components' forces you to 'abstract' the
components from the rest of the App
- they become little 'black boxes'
- this makes them much easier to test and debug

Eventually one lands up with an App where one 'programs' with a Text
Editor - you can add fields, modify their behavior and even create new
Forms and Reports without recompiling anything.

The initial investment is quite heavy, but even in the medium term it
pays off big time.

I and others have been using this approach since way back, well before
Windows was even dreamt of.  Like many things it goes back to the old
mainframe days.

HTH

Other Threads