Having never used FiveWin before, I am interested in just what it will do for me. As a result I have encountered the following problems, the last of which I am not able to resolve.
1. From what I gather the FiveWin demo is for the 16 bit Clipper. As I only have Blinker 1.0 which came with Clipper, I had to download and install both the Borland 16 bit compiler and the MS linker.
2. I had to learn how to create the app using the .bat file and modify it for my system.
3. The .bat file calls for a 501_520 library but I cannot find a library with that name in my Clipper 5.3b or the FiveWin demo.
Without that library, all I get is a large number of errors. I hope that is not the nornal way FiveWin operates!
Any suggestions to get a working demo would be appreciated.
The FiveWin Demo
Hi Ken,
First if want to go on with Fivewin 16 bits, you should get Blinker 7.0 for two reasons:
1. I don`t think that Blinker 1.0 supports Fivewin since it came out much sooner.
2. I remember having a lots of problems running applications under Win2000 and WinXP using Blinker 4.0. So I beleive that Blinker 1.0 would not do better. When I updated to 7.0, problems have vanished away.
The only thing that breaks my heart is that xHarbour cannot be linked with Blinker. Blinker beeing by far the best linker I have seen so far. So if you want to go 32 bits later on, Blinker will be of no use.
Regards
Gilbert
First if want to go on with Fivewin 16 bits, you should get Blinker 7.0 for two reasons:
1. I don`t think that Blinker 1.0 supports Fivewin since it came out much sooner.
2. I remember having a lots of problems running applications under Win2000 and WinXP using Blinker 4.0. So I beleive that Blinker 1.0 would not do better. When I updated to 7.0, problems have vanished away.
The only thing that breaks my heart is that xHarbour cannot be linked with Blinker. Blinker beeing by far the best linker I have seen so far. So if you want to go 32 bits later on, Blinker will be of no use.
Regards
Gilbert
Gilbert Vaillancourt
turbolog@videotron.ca
turbolog@videotron.ca
Hi Gilbert,
It is my intention to use xHarbour. Currently my apps are now ported and now work with xHarbour. However, from what I have seen and read, the FiveWin demo only works with 16 bits.
I understand their concerns re piracy, but it makes testing FiveWin difficult using the 16 bit version when ultimately I will be using 32 bits.
Regards,
Ken
It is my intention to use xHarbour. Currently my apps are now ported and now work with xHarbour. However, from what I have seen and read, the FiveWin demo only works with 16 bits.
I understand their concerns re piracy, but it makes testing FiveWin difficult using the 16 bit version when ultimately I will be using 32 bits.
Regards,
Ken
Hi Ken,
If you`re gonna port to Fivewin go with FWH right away, better do it right away. Then you can forget about upgrading Blinker.
Dont do like I did. I`m still using the 16 bit version, because I made major modifications to the class and would have to start over again.
I know I`ll have to it someday but for now I must finish what I have started.
Regards,
Gilbert
If you`re gonna port to Fivewin go with FWH right away, better do it right away. Then you can forget about upgrading Blinker.
Dont do like I did. I`m still using the 16 bit version, because I made major modifications to the class and would have to start over again.
I know I`ll have to it someday but for now I must finish what I have started.
Regards,
Gilbert
Gilbert Vaillancourt
turbolog@videotron.ca
turbolog@videotron.ca
-
James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Gilbert,
>Dont do like I did. I`m still using the 16 bit version, because I made major modifications to the class and would have to start over again.
Maybe FWH already supports what you made your modifications to do? Modifying a class is not a good approach, if it can be avoided. There are lots of ways to change the classes behavior without modifying the class such as using class codeblocks like bChange, bGotFocus, bLostFocus, etc. You can also subclass.
>I know I`ll have to it someday but for now I must finish what I have started.
Why? As you say, you are going to have to move to 32bit sometime. It sounds lke you are just throwing away more of your time. You can get lots of help with your conversion here on the newsgroup.
James
>Dont do like I did. I`m still using the 16 bit version, because I made major modifications to the class and would have to start over again.
Maybe FWH already supports what you made your modifications to do? Modifying a class is not a good approach, if it can be avoided. There are lots of ways to change the classes behavior without modifying the class such as using class codeblocks like bChange, bGotFocus, bLostFocus, etc. You can also subclass.
>I know I`ll have to it someday but for now I must finish what I have started.
Why? As you say, you are going to have to move to 32bit sometime. It sounds lke you are just throwing away more of your time. You can get lots of help with your conversion here on the newsgroup.
James
-
Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
OK, seems like my post has spawned a couple of points.
First, Antonio, my intention was to see what FW was capable of; hence my interest in the demo. I finally produced a working executable but it would have been nice if FW provided a little more introductory info such as:
1. To use the Demo, you must have Clipper 5.01 or 5.2. Clipper 5.3 will not work.
2. All linkers that come as part of the Clipper package are not able to link the resulting FW object files.
Since the demo only supports Clipper 5.01 or 5.2, attempting to link with a 5.3 object leads to a whole lot of errors similar to the following:
Five.lib(DIALOG) : error L2029: 'CLIPPER520' : unresolved external bad references
FW is looking for Clipper520 while the Clipper 5.3 compiled object contains Clipper530. FW should change its code to include Clipper 5.3 in it's Demo. Then there is the question about someone who has never had Clipper. How can they test FW?
I have an unrelated question relating to my evaluation. I would like to clarify whether it is possible to migrate to FW in stages, that is, use some screens as a text console while others as GUI? From the little I have learned so far, I would assume your answer to be no.
I really can’t afford to purchase both xHarbour and FW at the moment. It may be callous but I feel that a number of xHarbour functions are still in the development stage especially debug. Also their documentation provides little info on most of xHarbour’s extended functions. There have been complaints regarding the documentation. While new documentation has just been released; who knows just how complete it is. One post asked about a GUI problem and the response was to use GTGUI, a non supported library that needed to be created instead of the supported GTWIN. I do not feel like paying for a package that is still in beta. At least FW has been around for many years and they have concentrated primarily on GUI. As a result, I would hope the documentation is detailed and the change from text console to GUI would be smooth.
Gilbert, to respond your comments. I was quite happy using the basic Clipper 5.3. Only within the past year did I add-on PageScript for Clipper. Prior to that I could run the app in either DOS or Windows; but now only Windows. I compile using Blinker 1.0 that came with 5.3 and the resulting executables works with all flavours of Windows OS’s (at least Win 95 and up) without any problems. I found that as my files got larger I had to resort to moving more code to the overlay. I tried Exospace by I had problems especially when using debug so I just stuck with Blinker.
With the introduction of Vista next year, Microsoft will finally say good bye to the 16 bit apps and including DOS. It is for this reason that I am moving now while I have time to learn, experiment and perfect. I would not want to miss a potential sale by not being able to run on Vista. Fortunately, I have ported to xHarbour with few problems so you could say I am now Vista ready. The existing xHarbour Achoice and Tbrowse functions did have bugs but were quickly fixed although they not yet part of the Open Source or commercial libraries. I assume FW has replacements for these functions.
It sounds like you are still using Clipper + FW. I would agree with James that it is better to move sooner rather than later, that is unless you are under a time constraint. My situation is more dramatic in that I must move all my displays from a text console mode to Windows. On the other hand since I currently do not have FW, it was easier, and cheaper, to port to xHarbour.
Regards,
Ken
First, Antonio, my intention was to see what FW was capable of; hence my interest in the demo. I finally produced a working executable but it would have been nice if FW provided a little more introductory info such as:
1. To use the Demo, you must have Clipper 5.01 or 5.2. Clipper 5.3 will not work.
2. All linkers that come as part of the Clipper package are not able to link the resulting FW object files.
Since the demo only supports Clipper 5.01 or 5.2, attempting to link with a 5.3 object leads to a whole lot of errors similar to the following:
Five.lib(DIALOG) : error L2029: 'CLIPPER520' : unresolved external bad references
FW is looking for Clipper520 while the Clipper 5.3 compiled object contains Clipper530. FW should change its code to include Clipper 5.3 in it's Demo. Then there is the question about someone who has never had Clipper. How can they test FW?
I have an unrelated question relating to my evaluation. I would like to clarify whether it is possible to migrate to FW in stages, that is, use some screens as a text console while others as GUI? From the little I have learned so far, I would assume your answer to be no.
I really can’t afford to purchase both xHarbour and FW at the moment. It may be callous but I feel that a number of xHarbour functions are still in the development stage especially debug. Also their documentation provides little info on most of xHarbour’s extended functions. There have been complaints regarding the documentation. While new documentation has just been released; who knows just how complete it is. One post asked about a GUI problem and the response was to use GTGUI, a non supported library that needed to be created instead of the supported GTWIN. I do not feel like paying for a package that is still in beta. At least FW has been around for many years and they have concentrated primarily on GUI. As a result, I would hope the documentation is detailed and the change from text console to GUI would be smooth.
Gilbert, to respond your comments. I was quite happy using the basic Clipper 5.3. Only within the past year did I add-on PageScript for Clipper. Prior to that I could run the app in either DOS or Windows; but now only Windows. I compile using Blinker 1.0 that came with 5.3 and the resulting executables works with all flavours of Windows OS’s (at least Win 95 and up) without any problems. I found that as my files got larger I had to resort to moving more code to the overlay. I tried Exospace by I had problems especially when using debug so I just stuck with Blinker.
With the introduction of Vista next year, Microsoft will finally say good bye to the 16 bit apps and including DOS. It is for this reason that I am moving now while I have time to learn, experiment and perfect. I would not want to miss a potential sale by not being able to run on Vista. Fortunately, I have ported to xHarbour with few problems so you could say I am now Vista ready. The existing xHarbour Achoice and Tbrowse functions did have bugs but were quickly fixed although they not yet part of the Open Source or commercial libraries. I assume FW has replacements for these functions.
It sounds like you are still using Clipper + FW. I would agree with James that it is better to move sooner rather than later, that is unless you are under a time constraint. My situation is more dramatic in that I must move all my displays from a text console mode to Windows. On the other hand since I currently do not have FW, it was easier, and cheaper, to port to xHarbour.
Regards,
Ken
-
James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Ken,
>First, Antonio, my intention was to see what FW was capable of; hence my interest in the demo. I finally produced a working executable but it would have been nice if FW provided a little more introductory info such as:...
Probably a good idea, but at this point I suspect there are very few people looking at the Demo. You are one of the last DOS holdouts.
>I would like to clarify whether it is possible to migrate to FW in stages, that is, use some screens as a text console while others as GUI? From the little I have learned so far, I would assume your answer to be no.
No, and I can't see why you would want to. Your users certainly wouldn't like it and you couldn't sell an application like that.
Windows programs have a whole different set of interface standards. An application that had mixed Windows and DOS interfaces would be a nightmare for users.
I will also make this point. My advice is not to try to make your Windows version of your DOS applications look and work like a DOS application. If don't do this and you have a current user base, they might complain for a few weeks, but that will end quickly.
If you do make a Windows app that works likes a DOS app you might not get as many complaints, but you just have a poorly designed Windows application that still needs to be reworked to use Windows interface design standards. It is much less work and easier for the users in the long run to redesign it to Windows standards while you are converting it to FW.
>I really can’t afford to purchase both xHarbour and FW at the moment.
I am guessing that you are not aware that the free version of xHarbour comes with FWH. So, you only have to purchase FWH. There is another version of xHarbour (that costs) that provides additional features, but many of us either don't need them or are unwilling to pay the price.
>It may be callous but I feel that a number of xHarbour functions are still in the development stage especially debug.
Such as? In my experience xHarbour is far more stable and advanced than Clipper. And it is 32bit which eliminates all kinds of memory problems that Clipper has.
>Also their documentation provides little info on most of xHarbour’s extended functions. There have been complaints regarding the documentation. While new documentation has just been released; who knows just how complete it is. One post asked about a GUI problem and the response was to use GTGUI, a non supported library that needed to be created instead of the supported GTWIN. I do not feel like paying for a package that is still in beta.
As I said, xHarbour is free and just because it is called "beta" doesn't mean that it is not as stable as Clipper. Poor documentation is always an issue with any language, but you have an excellent support system in the newsgroups.
>At least FW has been around for many years and they have concentrated primarily on GUI. As a result, I would hope the documentation is detailed and the change from text console to GUI would be smooth.
Again you can always turn to the newgroup for questions not answered in the documentation.
>Gilbert, to respond your comments. I was quite happy using the basic Clipper 5.3. Only within the past year did I add-on PageScript for Clipper.
Hmm. You were quite happy, but what about your users? As programmers it is our job (generally) to make users happy, not ourselves.
>Prior to that I could run the app in either DOS or Windows; but now only Windows. I compile using Blinker 1.0 that came with 5.3 and the resulting executables works with all flavours of Windows OS’s (at least Win 95 and up) without any problems. I found that as my files got larger I had to resort to moving more code to the overlay. I tried Exospace by I had problems especially when using debug so I just stuck with Blinker.
How many DOS or Win 95 machines are there still? Not a market I would be going after.
No more EXE size limits nor memory problems with 32bit.
>With the introduction of Vista next year, Microsoft will finally say good bye to the 16 bit apps and including DOS. It is for this reason that I am moving now while I have time to learn, experiment and perfect. I would not want to miss a potential sale by not being able to run on Vista.
May I ask what type of application you are producing. I can think of very few, such as cash-register apps, that would not be much easier to sell with a Windows interface.
>Fortunately, I have ported to xHarbour with few problems so you could say I am now Vista ready. The existing xHarbour Achoice and Tbrowse functions did have bugs but were quickly fixed although they not yet part of the Open Source or commercial libraries. I assume FW has replacements for these functions.
Yes, you won't be using either achoice or tbrowse under FWH.
It sounds like you are still using Clipper + FW. I would agree with James that it is better to move sooner rather than later, that is unless you are under a time constraint.
I would say all the more reason to go directly to 32bit when one is under a time constraint. I can't tell you how many hours I spent trying to solve memory issues with FW/Clipper. Then there are printer driver issues too. And long filename issues, and...
>My situation is more dramatic in that I must move all my displays from a text console mode to Windows. On the other hand since I currently do not have FW, it was easier, and cheaper, to port to xHarbour.
I highly recommend that you get a copy of Alan Cooper's book, "About Face 2.0, The Essentials of Interaction Design." There is no better book on Windows interface design, and I consider it to be the most valuable computer book I own. You really need to read this BEFORE you start any conversion. You can find details about it on my website.
There are also several articles I wrote about FW there. There is one, "Introduction to FW" that will be most useful to you at this point.
Find them here:
http://ourworld.compuserve.com/homepage ... rogram.htm
Regards,
James
>First, Antonio, my intention was to see what FW was capable of; hence my interest in the demo. I finally produced a working executable but it would have been nice if FW provided a little more introductory info such as:...
Probably a good idea, but at this point I suspect there are very few people looking at the Demo. You are one of the last DOS holdouts.
>I would like to clarify whether it is possible to migrate to FW in stages, that is, use some screens as a text console while others as GUI? From the little I have learned so far, I would assume your answer to be no.
No, and I can't see why you would want to. Your users certainly wouldn't like it and you couldn't sell an application like that.
Windows programs have a whole different set of interface standards. An application that had mixed Windows and DOS interfaces would be a nightmare for users.
I will also make this point. My advice is not to try to make your Windows version of your DOS applications look and work like a DOS application. If don't do this and you have a current user base, they might complain for a few weeks, but that will end quickly.
If you do make a Windows app that works likes a DOS app you might not get as many complaints, but you just have a poorly designed Windows application that still needs to be reworked to use Windows interface design standards. It is much less work and easier for the users in the long run to redesign it to Windows standards while you are converting it to FW.
>I really can’t afford to purchase both xHarbour and FW at the moment.
I am guessing that you are not aware that the free version of xHarbour comes with FWH. So, you only have to purchase FWH. There is another version of xHarbour (that costs) that provides additional features, but many of us either don't need them or are unwilling to pay the price.
>It may be callous but I feel that a number of xHarbour functions are still in the development stage especially debug.
Such as? In my experience xHarbour is far more stable and advanced than Clipper. And it is 32bit which eliminates all kinds of memory problems that Clipper has.
>Also their documentation provides little info on most of xHarbour’s extended functions. There have been complaints regarding the documentation. While new documentation has just been released; who knows just how complete it is. One post asked about a GUI problem and the response was to use GTGUI, a non supported library that needed to be created instead of the supported GTWIN. I do not feel like paying for a package that is still in beta.
As I said, xHarbour is free and just because it is called "beta" doesn't mean that it is not as stable as Clipper. Poor documentation is always an issue with any language, but you have an excellent support system in the newsgroups.
>At least FW has been around for many years and they have concentrated primarily on GUI. As a result, I would hope the documentation is detailed and the change from text console to GUI would be smooth.
Again you can always turn to the newgroup for questions not answered in the documentation.
>Gilbert, to respond your comments. I was quite happy using the basic Clipper 5.3. Only within the past year did I add-on PageScript for Clipper.
Hmm. You were quite happy, but what about your users? As programmers it is our job (generally) to make users happy, not ourselves.
>Prior to that I could run the app in either DOS or Windows; but now only Windows. I compile using Blinker 1.0 that came with 5.3 and the resulting executables works with all flavours of Windows OS’s (at least Win 95 and up) without any problems. I found that as my files got larger I had to resort to moving more code to the overlay. I tried Exospace by I had problems especially when using debug so I just stuck with Blinker.
How many DOS or Win 95 machines are there still? Not a market I would be going after.
No more EXE size limits nor memory problems with 32bit.
>With the introduction of Vista next year, Microsoft will finally say good bye to the 16 bit apps and including DOS. It is for this reason that I am moving now while I have time to learn, experiment and perfect. I would not want to miss a potential sale by not being able to run on Vista.
May I ask what type of application you are producing. I can think of very few, such as cash-register apps, that would not be much easier to sell with a Windows interface.
>Fortunately, I have ported to xHarbour with few problems so you could say I am now Vista ready. The existing xHarbour Achoice and Tbrowse functions did have bugs but were quickly fixed although they not yet part of the Open Source or commercial libraries. I assume FW has replacements for these functions.
Yes, you won't be using either achoice or tbrowse under FWH.
It sounds like you are still using Clipper + FW. I would agree with James that it is better to move sooner rather than later, that is unless you are under a time constraint.
I would say all the more reason to go directly to 32bit when one is under a time constraint. I can't tell you how many hours I spent trying to solve memory issues with FW/Clipper. Then there are printer driver issues too. And long filename issues, and...
>My situation is more dramatic in that I must move all my displays from a text console mode to Windows. On the other hand since I currently do not have FW, it was easier, and cheaper, to port to xHarbour.
I highly recommend that you get a copy of Alan Cooper's book, "About Face 2.0, The Essentials of Interaction Design." There is no better book on Windows interface design, and I consider it to be the most valuable computer book I own. You really need to read this BEFORE you start any conversion. You can find details about it on my website.
There are also several articles I wrote about FW there. There is one, "Introduction to FW" that will be most useful to you at this point.
Find them here:
http://ourworld.compuserve.com/homepage ... rogram.htm
Regards,
James
James,
Everything you say makes sense, however, I am puzzled by one comment. You say:
"the free version of xHarbour comes with FWH. So, you only have to purchase FWH"
Why would you need to purchase FWH if it were free?
In the xHarbour Getting Started Guide, I have seen several references to the FW App.
I have downloaded your article on FW and will read it tonight. As for the book, I see it is available at Amazon and will order it in the next few days.
Regards,
ken
Regards,
Ken
Everything you say makes sense, however, I am puzzled by one comment. You say:
"the free version of xHarbour comes with FWH. So, you only have to purchase FWH"
Why would you need to purchase FWH if it were free?
In the xHarbour Getting Started Guide, I have seen several references to the FW App.
I have downloaded your article on FW and will read it tonight. As for the book, I see it is available at Amazon and will order it in the next few days.
Regards,
ken
Regards,
Ken
-
James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Ken,
>"the free version of xHarbour comes with FWH. So, you only have to purchase FWH"
>Why would you need to purchase FWH if it were free?
FWH is not free. xHarbour is free (or rather there is a free version). The free version of xHarbour comes with FWH.
>As for the book, I see it is available at Amazon and will order it in the next few days.
If you click on the link from my website it takes you directly to the Amazon page. If you purchase it by using my link, I get a (tiny) commisson. The price is the same and you are still purchasing it directly from Amazon.
James
>"the free version of xHarbour comes with FWH. So, you only have to purchase FWH"
>Why would you need to purchase FWH if it were free?
FWH is not free. xHarbour is free (or rather there is a free version). The free version of xHarbour comes with FWH.
>As for the book, I see it is available at Amazon and will order it in the next few days.
If you click on the link from my website it takes you directly to the Amazon page. If you purchase it by using my link, I get a (tiny) commisson. The price is the same and you are still purchasing it directly from Amazon.
James
-
James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Ken,
You may also find this article interesting.
Magic and Software Design
http://www.asktog.com/papers/magic.html
This is a rather long article in small type, but it is worth wading through. It presents some unique thoughts.
You might also want to read some of my other postings on interface design on this forum. Try searching for "design" and author "James Bott"
James
You may also find this article interesting.
Magic and Software Design
http://www.asktog.com/papers/magic.html
This is a rather long article in small type, but it is worth wading through. It presents some unique thoughts.
You might also want to read some of my other postings on interface design on this forum. Try searching for "design" and author "James Bott"
James
-
Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Ken,
>
1. To use the Demo, you must have Clipper 5.01 or 5.2. Clipper 5.3 will not work.
>
Clipper 5.3 works fine with FW. All you need is to declare this function in your code:
function CLIPPER520()
return nil
>
2. All linkers that come as part of the Clipper package are not able to link the resulting FW object files.
>
FW requires a Windows capable linker. Thats a Windows design requirement. You may use Microsoft free link.exe for your tests. Its available from different places, and you can find a copy here: http://www.geocities.com/ninguno_todos/link.zip
>
Then there is the question about someone who has never had Clipper. How can they test FW?
>
Yes, you are right. Thats a limitation, though many Harbour users have been Clipper users too.
>
1. To use the Demo, you must have Clipper 5.01 or 5.2. Clipper 5.3 will not work.
>
Clipper 5.3 works fine with FW. All you need is to declare this function in your code:
function CLIPPER520()
return nil
>
2. All linkers that come as part of the Clipper package are not able to link the resulting FW object files.
>
FW requires a Windows capable linker. Thats a Windows design requirement. You may use Microsoft free link.exe for your tests. Its available from different places, and you can find a copy here: http://www.geocities.com/ninguno_todos/link.zip
>
Then there is the question about someone who has never had Clipper. How can they test FW?
>
Yes, you are right. Thats a limitation, though many Harbour users have been Clipper users too.
-
James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Ken,
One more thing. While you are purchasing About Face, you should also get a copy of "Business Engineering With Object Technology," David A. Taylor; also available via my site. You can get a used copy for 28 cents (plus shipping)!
If you don't already know this, FW is built using Object Oriented Programming, so you really need to understand OOP to get the most out of it.
FW deals with interface objects. The book I am recommending is about building objects that simulate real-world objects, such as customers, orders, items, etc. It does not get into programming but only the concepts and it is easy to read.
There are also a couple of articles I wrote on this topic with FW code examples on my site.
Since you are already going to be doing a conversion, now is the time to get a handle on this. I don't remember if I discussed the concept of OOP wrappers in my articles, but you can use wrappers around legacy code to get them into a class which makes subseqent programming much easier. I know it seems like it would be easier not to do this, but after having learned OOP, I can tell you it is very much easier than procedural programming.
A little time spent learning interface design and OOP now will pay back greatly in the future.
James
One more thing. While you are purchasing About Face, you should also get a copy of "Business Engineering With Object Technology," David A. Taylor; also available via my site. You can get a used copy for 28 cents (plus shipping)!
If you don't already know this, FW is built using Object Oriented Programming, so you really need to understand OOP to get the most out of it.
FW deals with interface objects. The book I am recommending is about building objects that simulate real-world objects, such as customers, orders, items, etc. It does not get into programming but only the concepts and it is easy to read.
There are also a couple of articles I wrote on this topic with FW code examples on my site.
Since you are already going to be doing a conversion, now is the time to get a handle on this. I don't remember if I discussed the concept of OOP wrappers in my articles, but you can use wrappers around legacy code to get them into a class which makes subseqent programming much easier. I know it seems like it would be easier not to do this, but after having learned OOP, I can tell you it is very much easier than procedural programming.
A little time spent learning interface design and OOP now will pay back greatly in the future.
James
-
Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact: