Do you mean what is needed to:
a) convert existing Pascal code to Delphi
or
b) upgrade your programming software from Pascal to Delphi
Clive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer."
Paul Ehrlich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096
Both. But more of a knowledge transfer kind of upgrade than a technical issue. Basically:
1) What tricks have changed between TP/BP 7.0 and Delphi?
2) What tricks in TP/BP 7.0 are not a good idea in Delphi?
3) What new tricks does Delphi have that TP/BP 7.0 did not?
TP teached sequence driven programming, you make a program and it runs top to bottom (in most cases)
Delphi is event driven programming (in most cases). The programs hunts for the input, (mouse clicks etc.) and act corresponding to that.
I stopped at TP 6.0, took a time out of almost 5 years and the book that get me started was Teach yourself Delphi 3 in 21 days from Sams publishing. It explained the difference between traditional programming and event driven Windows programming very well, so the transition was very easy.
Maybe I'm not being too clear about what I'm looking for. I do have a Visual Basic background as well, so I'm OK on using most of the visual components of Delphi, and muddled my way through the control aspects (changing forms, picking values off of controls, and so on).
I do have a book: Teach Yourself Delphi 3 in 14 days from Sams Publishing. It was useful to explain how a few of the widgets work, but really doesn't go towards any of the technical parts of programming in Delphi - especially towards some of the questions I have regarding doing some of the same tricks in both Pascal and Delphi, and especially towards what is "totally new" in Delphi.
I'll put one of my main questions right now in another thread.
Delphi is just a *Rapid Application Development* wrapper for Pascal32 code. If you can write in Object Pascal ... you only need to concern youself with learning the Delphi development environment and that is actually very easy for the most part.
Well I'm not exactly finding that to be the case - I'm discovering there are many differences even to what I'm doing. Like where is the CRT function stuff (even stuff not related to the screen)? What about memory allocation (which I posted another thread on asking for some explanations)? I find that is a totally different animal for Delphi than it was under TP 7.0. And if I have a program code tied up in a form that takes longer than a few moments to complete, I have the app tied up so the controls won't respond. I find I needed to do thread management to solve that one, which wasn't a TP 7.0 Object Pascal thing.
I'm finding there's much more to it than just applying TP 7.0 style object Pascal. And that's what I'm asking, how do I find out what the differences are that I need to know?
Of course, I have more questions about Windows and the interface that the before mentioned book doesn't answer, which I'm sure I'll probably post in here when I get to them.
There is more to Delphi than just hacking some Pascal code into a Windows suite. I can feel your pain because I have gone through it also. I have written TP programs for years starting with TP 3.01 and ending with TP 6.0 before Delphi existed. My programs were the type of:
Input, calculate/draw something, output (screen, printer, file)
OOP was focused on my variables, I defined Vectors, Matrixes etc. like objects. I read something about OOP in TP manuals, but that was dealing with forms etc. like objects (the bells end whistles).
When I saw Delphi 2, actually received a copy, I was also lost, because for a traditional programmer it was totally greek.
My first delphi program was to convert a program that was calculating balancing weights for machinery (my mechanical background)
Traditional: 1)read the variables,
2) check if they are valid readln, clreol, gotoxy, $I-, $I+ enfim, the whole graphical handling on screen found in the crt unit
3) Process the variables (functions, procedures) put them in the very original Calc unit
4) Output to screen/printer (the same crt functions/procedures
Delphi approach
1) Make a form
2) Place editboxes for the input, Editboxes have strings so you will need to convert them to integers, double (real is not supported anymore) etc. Characters can be disabled in the editbox
3) Put a button with the "original" caption calculate
and in its onclick event, I converted values, checked if every thing needed existed and called my functions/procedures to do the calculation.
4) Put the output in a stringgrid, converting the numerical variables to strings.
The rest was rad stuff, drag and drop. Put in a menubar starting with file and ending with help
Of course the help had only an about box
Put in a drawing visualizing the machinery and sensors (made a bitmap and loaded it into a timage).
The hardest part were still the calculations...
I never did thread management and just some simple memory allocation for linked lists etc.
One word of caution with forms, it is easy to put in a lot of bells and wistles using spinedits, gauges and other kind of fancy stuff, but I found that I was loosing more time cliking with the mouse, if the program must take value A, sum it with Value B, and give the result in C, there is no mouse needed.
Keep in mind KISS Keep It Simple (not S...)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.