Let me apologize up front about the length of this post, but I want to
get opinions and I need to provide some background...

In the 90's, I worked as an independent contractor and designed a set
of customized quote generation programs (4 total, one for each product
line) for a client in VB4.0 16 bit using Access databases. Basically
the user enters customer information, application information and
specifies model parameters if desired and the program goes through a
bunch of engineering calculations to select the best model for the
applicaiton. At that point the user can select options/accessories
and a quote is generated in either Crystal Report format or MS Word
format.

I can't claim to be a great coder, but I managed to teach myself
enough to get the job done - probably not very efficiently :) These
programs are distributed world-wide to their reps and therefore used
on new/old computers and a range of operating systems. Over the years
we worked out any bugs/issues as they popped up and the programs were
quite reliable.

Around 2001, I pursued a lifelong dream of becoming a teacher and cut
back my programming hours considerably (8-12 week). After spending a
year or two maintaining the programs, working on other projects
(website, etc) and dabbling with the thought of converting them to
VB6.0, we decided to wait for VB.net 2003. Once that came out we
started the process of converting them. Much to my frustration, it
wasn't nearly as simple as Microsoft made it sound and the learning
curve was STEEP. It didn't help that every time I started to make
substantial headway, I would be sidetracked by other projects for the
client. Not a very efficient way to learn a language. In the
meantime, every year I would update the pricing in the databases and
send out the VB4.0 programs via CD. I've basically updated only one
of the four programs to VB.net at this point because everytime I take
two steps forward, I get sidetracked for a long period of time and
then have to figure things out again.

Here's where I need your thoughts/input. Over the last year or two
I've spoken openly with my client about the inefficiencies of this
arrangement and about my concerns with the potential of the programs
not to work properly anymore. With Windows Vista, I think we may have
run into this issue head-on.

Two weeks ago, a rep bought a machine with Vista Ultimate. He
installed my application programs and we have discovered that any
labels that were placed on either the SSPanel or SSFrame controls
don't show up at all - they are basically invisible. Labels on the
standard panel or frame controls work perfectly. Even more
interesting is that I asked the rep to walk through the entire quote
generation process and his initial report is that it seems to work
fine except the missing labels (I was very surprised to hear that)

1) Does anyone have any idea what might cause this issue and how I
can fix it? The easy answer is to convert to standard controls but
before I go about that (there are a lot of forms using SS controls), I
thought maybe there was an easier way. Especially because I use the
SSTab control and that won't be easy to replace in my layout.

Any help would be appreciated. Of even greater interest is your
opinions on the next topic. While trying to find out a bit about Vista
compatibility, I came across an article which indicates the VB.net
2003 and even VB.net 2005 may not be fully supported by Vista (http://
www.theserverside.net/news/thread.tss?thread_id=42426). This really
surprised me and led to a discussion that I need your opinions on.

2) My client initially wants to just get the programs so they can be
installed on a Vista machine. Can I do this with VB4.0 16 bit
programs or am I going to be looking at a ton of other issues?

3) After we get them at least functioning on Vista, we want to
obviously upgrade them. What's the best route to go? We have to
decide what programming environment to invest our time/energy in. The
link above makes me question continuing on the VB.net journey (which I
haven't even looked at in 4 months because of other projects). There
has long been a thought of making them web-based to greatly simplify
distribution/updgrades,etc. One of the potential negatives would be
the requirement for internet access (often the reps are traveling
pretty remotely) and/or speed of internet access. What helps you
decide to go web-based vs stand-alone application? What positives/
negatives should I be aware of?

If we send them out as a stand-alone application, what language should
we consider developing them in? Obviously we don't want to go down a
road that ends up being a dead end in the near future.

Unfortunately with my limited hours, I haven't been able to keep up on
the trends in programming. I'm trying to get a feel of what avenues I
should explore. In advance, let me thank anyone who provides a bit of
insight into this murky situation.

Sincerely,

Jmar

P.S. Please don't go into a discussion about how the client should
spend more money or hire someone full-time, etc. Budget constraints
have dictated many of their decisions and will continue to do so. The
programs have been sufficient to get by with and many of their reps
are always behind when it comes to technology at the latest hardware/
software.

> Around 2001, I pursued a lifelong dream of becoming a teacher and cut
> back my programming hours considerably (8-12 week). After spending a
> year or two maintaining the programs, working on other projects
> (website, etc) and dabbling with the thought of converting them to
> VB6.0, we decided to wait for VB.net 2003.

Just so you know, if you stick with VB.NET, then this is the wrong newsgroup
to post questions in. You will want newsgroups with "dotnet" in their names.
However, not all of your questions are VB.NET related, so read on for some
of my thoughts and responses to your other questions.


> Once that came out we started the process of converting them.
> Much to my frustration, it wasn't nearly as simple as Microsoft
> made it sound and the learning curve was STEEP.

We have a couple of VB.NET advocates who visit us on occasion who keep
telling us that VB2005 is almost the same as VB6... no one here really
believes them; we have seen others post the same kinds of comments you have.
However, there does seem to be a consensus that if you are going stay in the
VB.NET world, VB2005 is supposed to be much superior to VB2003 (or its
predeccessors).


> Two weeks ago, a rep bought a machine with Vista Ultimate. He
> installed my application programs and we have discovered that any
> labels that were placed on either the SSPanel or SSFrame controls
> don't show up at all - they are basically invisible. Labels on the
> standard panel or frame controls work perfectly. Even more
> interesting is that I asked the rep to walk through the entire quote
> generation process and his initial report is that it seems to work
> fine except the missing labels (I was very surprised to hear that)
>
> 1) Does anyone have any idea what might cause this issue and how I
> can fix it? The easy answer is to convert to standard controls but
> before I go about that (there are a lot of forms using SS controls), I
> thought maybe there was an easier way. Especially because I use the
> SSTab control and that won't be easy to replace in my layout.

Another possibility is to replace the Labels with TextBoxes that have their
Locked property set to True. I don't use VB.NET myself, so I am not positive
on this point, but I think Labels and TextBoxes have the same "text"
property (this is not the case in VB6 where Labels have Captions and
TextBoxes have Text for this purpose). If that is the case, then simply
naming the TextBoxes the same as the Labels they replace might make
everything work immediately (unless you are processing Label events instead
of just using the Labels to label things; that would require a little more
work for this idea in that case).


> 2) My client initially wants to just get the programs so they can be
> installed on a Vista machine. Can I do this with VB4.0 16 bit
> programs or am I going to be looking at a ton of other issues?

There is a difference between 16-bit and 32-bit versions of Vista product
support-wise. I have the 64-bit version of Vista Ultimate on my laptop and
there are program incompatibilities. What I have done in some of those cases
is to use Microsoft Virtual PC to install Windows XP Pro and run my programs
there. Note that Virtual PC is **not** a dual-boot solution; rather, the
operating systems you install in it run in a window just like any other
program. It is really pretty neat to see Window XP Pro boot up inside of a
window that I can jump back and forth between at will. Anyway, the reason I
mention this option is because Microsoft Virtual PC is a free program, so
implementing it as a solution is quite easy. Here is a link for more
information about it...

[url down]

I guess another thing to your client could try is Vista's compatibility mode
settings, but I didn't have much success with that option for my older
programs that wouldn't run on Vista.


> If we send them out as a stand-alone application, what language should
> we consider developing them in? Obviously we don't want to go down a
> road that ends up being a dead end in the near future.

That is the question of the day. Many people feel that Microsoft shafted the
VB classic community (version 6 and earlier) by not providing an upgrade
path that supported existing code assets. You are finding out about the
problems associated with trying to move your code forward first hand.
Anyway, these same people make a compelling argument that if Microsoft
abandoned the VB classic community so easily, what is to stop them from
doing so with the VB.NET community a few years from now when they decide a
new direction is needed? There are many and long discussions in these
newsgroups devoted to the topic of where to go from here. You might try
Googling around to try and find them. Delphi (a Pascal based language) is a
programming language that has been pushed for moving to. I, personally, like
a product called REALbasic ([url down]) because it BASIC
language roots, but is also Object Oriented. It is a small company, but I
feel confident with them as REALbasic is their only product... if they fail
to keep it working with whatever operating system Microsoft throws at us,
they will be out of business... seems like a great incentive to keep the
product fully up to date. Anyway, there is no clear cut answer as what to
do... anything you do will have an element of risk to it.


Rick

On 19 May 2007 20:10:27 -0700, jmar <jmarzion> wrote:
in <1179630627.606527.301050>

[..]
>started the process of converting them. Much to my frustration, it
>wasn't nearly as simple as Microsoft made it sound and the learning
>curve was STEEP. It didn't help that every time I started to make
>substantial headway, I would be sidetracked by other projects for the
>client. Not a very efficient way to learn a language. In the
>meantime, every year I would update the pricing in the databases and
>send out the VB4.0 programs via CD. I've basically updated only one
>of the four programs to VB.net at this point because everytime I take
>two steps forward, I get sidetracked for a long period of time and
>then have to figure things out again.

This is by design and is exactly as microsoft wants it and basically
unless you can keep up, you're screwed - so don't bother. You're much
better off if you look around at the competition and see what else is
available.

>Here's where I need your thoughts/input. Over the last year or two
>I've spoken openly with my client about the inefficiencies of this
>arrangement and about my concerns with the potential of the programs
>not to work properly anymore. With Windows Vista, I think we may have
>run into this issue head-on.
>

And that is intentional also. Just Google around for Vista problems and
it should become more apparent.

[..]
>before I go about that (there are a lot of forms using SS controls), I
>thought maybe there was an easier way. Especially because I use the
>SSTab control and that won't be easy to replace in my layout.
>
>Any help would be appreciated. Of even greater interest is your
>opinions on the next topic. While trying to find out a bit about Vista
>compatibility, I came across an article which indicates the VB.net
>2003 and even VB.net 2005 may not be fully supported by Vista (http://
>[..]). This really
>surprised me and led to a discussion that I need your opinions on.

It's a big guessing game as to what is supported and basically microsoft
could care less since you're daring to use such an antiquated
development system.

>2) My client initially wants to just get the programs so they can be
>installed on a Vista machine. Can I do this with VB4.0 16 bit
>programs or am I going to be looking at a ton of other issues?
>

I would look at any other vendor's development platforms since microsoft
has made the move towards ignoring and laughing at any VB6 development
efforts.


>3) After we get them at least functioning on Vista, we want to
>obviously upgrade them. What's the best route to go? We have to
>decide what programming environment to invest our time/energy in. The
>link above makes me question continuing on the VB.net journey (which I
>haven't even looked at in 4 months because of other projects). There
>has long been a thought of making them web-based to greatly simplify
>distribution/updgrades,etc. One of the potential negatives would be
>the requirement for internet access (often the reps are traveling
>pretty remotely) and/or speed of internet access. What helps you
>decide to go web-based vs stand-alone application? What positives/
>negatives should I be aware of?
>

Choose any vendor other than microsoft to develop your software and
you'll have an infinitely easier time migrating forwards than you would
if you stick with their offerings.


>If we send them out as a stand-alone application, what language should
>we consider developing them in? Obviously we don't want to go down a
>road that ends up being a dead end in the near future.
>

Anything but any of the .NET development platforms. Stay away
especially from VB.NET.


>Unfortunately with my limited hours, I haven't been able to keep up on
>the trends in programming. I'm trying to get a feel of what avenues I
>should explore. In advance, let me thank anyone who provides a bit of
>insight into this murky situation.
>

I've spent all my available hours trying to salvage my code assets and
move them forward into something that microsoft can't kill whenever it
gets bored - which seems to be about every other week. I finally have
all of my SQL Server code assets migrated into PostgreSQL and what a
relief! Now just as soon as I can rescue the rest of my code assets
I'll be safe.
[..]

"jmar" <jmarzion> wrote
>
> 2) My client initially wants to just get the programs so they can be
> installed on a Vista machine. Can I do this with VB4.0 16 bit
> programs or am I going to be looking at a ton of other issues?

<snipped for brievity>

> Unfortunately with my limited hours, I haven't been able to keep up on
> the trends in programming. I'm trying to get a feel of what avenues I
> should explore. In advance, let me thank anyone who provides a bit of
> insight into this murky situation.

As far as I am concerned, you can't get ahead on technology. It seems as
soon as you unbox and plug in your new whiz-bang computer, the next
'new and improved' version is already on the shelves. The same with software.

Likewise (and perhaps a minority position) trying to drag old code onto the
future desktops is an invitation for trouble. No other industry that I know of
tries to hold on to past successes (aka: code assets) as much as some in the
software industry. For whatever reason (usually cost in man-hours) some
want to keep applying band-aids and bailing wire to legacy applications instead
of getting back to a clean slate and bulding a better application. My bias is that
things are always changing, and those that refuse to change (upgrade, learn new
skills, etc.) are going to be phased out of a job. Of course, keeping legacy
code going could be classified under job security, but sooner or later, the bullet
has to be bitten and the clean slate brought in....

Could you imagine what it would be like other industries tried to force their first
products onto the market shelves long after their initial release? You'd need a pretty
big desk to hold a computer from the 1980's that would compute as fast as the
desktops today. Yet some have code from before that era....

It is absurd to think that thoughts put to paper (or to machine code) are going to
be the last word on that subject. For that reason I always favor asking yourself
if the next version warrents a re-design, or re-write, to take advantages of new
technology.

Two points I would suggest may interest you:

MS is working hard to make VS 2005 (SP1) work well on Vista.
http://www.microsoft.com/presspass/f...ualStudio.mspx
"With this update to Visual Studio, our goal was to ensure
developers have the best possible experience on Windows Vista,
and that the features developers are using in Visual Studio
work as expected."

And:

Click Once is a deployment model that supports web-based deployment and
a rich client interface. Best of both worlds, so to speak....
http://msdn.microsoft.com/en-us/netf.../aa497348.aspx
"ClickOnce applications can be deployed via web servers,
file servers or CDs. A ClickOnce application can choose
to be installed, meaning it gets start menu & add/remove
program entries, or an app can simply be run and cached."


Finally, you may want to expand your discussion to newsgroups that discuss
the .Net technology. This group is dedicated to Visual Basic, version 6 and
prior. e.g.: news:\\microsoft.public.dotnet.languages.vb

Good Luck!
LFS

I'll only make a few observations. Vista will undoubtedly screw with your
world. Microsoft could care less. VS2005 is far superior to any development
platform they have ever produced, but most of the controls have undocumented
bugs that have to be discovered and worked around. I suspect this is by
design -- why enable potential competitors? Anyway, by the time you have
found all of those undocumented issues, they will have moved on to the next
platform. In terms of language, I program in both C# and VB.Net and find
there is little difference between the two other than syntax. C# can get
things done in fewer lines of code, but the .Net paradigm really drives your
architectural design.

"jmar" <jmarzion> wrote in message
news:1050
[..]

"jmar" <jmarzion> wrote in message
news:1050
> Let me apologize up front about the length of this post, but I want to
> get opinions and I need to provide some background...
>> 1) Does anyone have any idea what might cause this issue and how I
> can fix it? The easy answer is to convert to standard controls but
> before I go about that (there are a lot of forms using SS controls), I
> thought maybe there was an easier way. Especially because I use the
> SSTab control and that won't be easy to replace in my layout.

There are lots of reports of installation issues with Vista, so one possibility
is that the SSLabel control did not get installed and registered correctly. Can
you do an installation on Vista yourself, for testing?

One way to convert back to standard controls would be to write a little program
that would open all of the .frm files, which are just text files. You should be
able to replace every occurence of SSLabel, or whatever it is, with Label. When
you open the project again, all labels will be converted to standard ones.
Obviously try it on copies, and look at a .frm file in notepad first.

> 2) My client initially wants to just get the programs so they can be
> installed on a Vista machine. Can I do this with VB4.0 16 bit
> programs or am I going to be looking at a ton of other issues?
>

I don't know for sure, but from the sound of what your rep experienced, it would
seem that in principle a VB4 app can run on Vista, if you can get it to install
correctly.


> 3) After we get them at least functioning on Vista, we want to
> obviously upgrade them. What's the best route to go?
>
>What helps you
> decide to go web-based vs stand-alone application? What positives/
> negatives should I be aware of?
>
> If we send them out as a stand-alone application, what language should
> we consider developing them in? Obviously we don't want to go down a
> road that ends up being a dead end in the near future.
>

IMO, VS 2005 is a better tool than VS 2003, and .Net Framework 2.0 is better
than 1.1. While the first year can be a long steep climb, you do get to a point
where you become productive again, once you figure out how to work the new deal.
You can go with non-MS tools, but there are still good reasons to stick with MS
tools if your users are running MS Windows. Certainly you should get into VB6,
if not .Net. I expect VB6 apps to continue to work on MS platforms for quite a
while yet.

My view of web apps is that they can work if the nature of the application is
well suited to the ping-pong nature of the web. User does a little bit, sends it
to the server, server does something, sends it back to the user. Typically the
client will not have much data loaded at one time, or a lot of code, so most of
the heavy lifting should be done on the server end. Would that work?

I have done one browser-based reporting app that gets a few selections from a
user, then retrieves data from a db server, creates a report as a PDF file, and
streams it back to the user. That works out quite nicely. The other app I am
currently working on needs a fair amount of data and code on the client end,
otherwise it would be too slow to work through, so that is not a browser app
(although it uses a web service to retrieve data, which does work out well).

I am amazed at the prompt, friendly and most importantly, useful
responses from everyone. I really appreciate you taking the time to
share your ideas and I welcome anyone else to add to the comments
already shared.

I'm also curious if anyone else has run into the issue I have with the
label on the SS controls not showing up...

Jmar

"jmar" <jmarzion> wrote in message
news:1050
> Let me apologize up front about the length of this post, but I want to
> get opinions and I need to provide some background...

I'd advice posting this question in other groups. Posting a question to a
VB6 group and asking what language to use is bound to give you biased
answers. Most people here are bitter about the improvements in VB7.

"Michael C" <nospam> wrote in message
news:3656
> "jmar" <jmarzion> wrote in message
> news:1050
>> Let me apologize up front about the length of this post, but I want to
>> get opinions and I need to provide some background...
>
> I'd advice posting this question in other groups. Posting a question to a
> VB6 group and asking what language to use is bound to give you biased
> answers. Most people here are bitter about the improvements in VB7.

Nobody is bitter about any "improvements". People are disgusted with the
failure to maintain the core language syntax and the lack of any viable
migration path. Keep trying, someday you may get it.

Coming from a hobbist who happens to make a few bucks in the process...dump
the VB.NET solution and go with VB6. You'll have way less headaches in code
conversion...plus without getting into a whole monolog about why VB.NET is
not the way to go, your general desktop solutions in VB.NET is serious
overkill.

Now, seeing your still using the 16 bit version of VB, you may have to make
some 32 bit conversions if you use the Windows API, plus potential upgrade
issues depending on what version of DAO/ADO you are using with your
databases. Access is not the most backwards compatible thing ever designed.

I'm sure many will diagree with my opinion as lots of folks consider VB 6
and lower a dead language, but if it works for you and your clients, I don't
see the need in your wasting time with a new language (and VB.NET is a new
language) when your existing code base will move to VB 6 a lot easier,
especially when considering your caseload of other projects.

Just my 2 cents.

- Kev

"jmar" <jmarzion> wrote in message
news:1050
| Let me apologize up front about the length of this post, but I want to
| get opinions and I need to provide some background...
|
| In the 90's, I worked as an independent contractor and designed a set
| of customized quote generation programs (4 total, one for each product
| line) for a client in VB4.0 16 bit using Access databases. Basically
| the user enters customer information, application information and
| specifies model parameters if desired and the program goes through a
| bunch of engineering calculations to select the best model for the
| applicaiton. At that point the user can select options/accessories
| and a quote is generated in either Crystal Report format or MS Word
| format.
|
| I can't claim to be a great coder, but I managed to teach myself
| enough to get the job done - probably not very efficiently :) These
| programs are distributed world-wide to their reps and therefore used
| on new/old computers and a range of operating systems. Over the years
| we worked out any bugs/issues as they popped up and the programs were
| quite reliable.
|
| Around 2001, I pursued a lifelong dream of becoming a teacher and cut
| back my programming hours considerably (8-12 week). After spending a
| year or two maintaining the programs, working on other projects
| (website, etc) and dabbling with the thought of converting them to
| VB6.0, we decided to wait for VB.net 2003. Once that came out we
| started the process of converting them. Much to my frustration, it
| wasn't nearly as simple as Microsoft made it sound and the learning
| curve was STEEP. It didn't help that every time I started to make
| substantial headway, I would be sidetracked by other projects for the
| client. Not a very efficient way to learn a language. In the
| meantime, every year I would update the pricing in the databases and
| send out the VB4.0 programs via CD. I've basically updated only one
| of the four programs to VB.net at this point because everytime I take
| two steps forward, I get sidetracked for a long period of time and
| then have to figure things out again.
|
| Here's where I need your thoughts/input. Over the last year or two
| I've spoken openly with my client about the inefficiencies of this
| arrangement and about my concerns with the potential of the programs
| not to work properly anymore. With Windows Vista, I think we may have
| run into this issue head-on.
|
| Two weeks ago, a rep bought a machine with Vista Ultimate. He
| installed my application programs and we have discovered that any
| labels that were placed on either the SSPanel or SSFrame controls
| don't show up at all - they are basically invisible. Labels on the
| standard panel or frame controls work perfectly. Even more
| interesting is that I asked the rep to walk through the entire quote
| generation process and his initial report is that it seems to work
| fine except the missing labels (I was very surprised to hear that)
|
| 1) Does anyone have any idea what might cause this issue and how I
| can fix it? The easy answer is to convert to standard controls but
| before I go about that (there are a lot of forms using SS controls), I
| thought maybe there was an easier way. Especially because I use the
| SSTab control and that won't be easy to replace in my layout.
|
| Any help would be appreciated. Of even greater interest is your
| opinions on the next topic. While trying to find out a bit about Vista
| compatibility, I came across an article which indicates the VB.net
| 2003 and even VB.net 2005 may not be fully supported by Vista (http://
| www.theserverside.net/news/thread.tss?thread_id=42426). This really
| surprised me and led to a discussion that I need your opinions on.
|
| 2) My client initially wants to just get the programs so they can be
| installed on a Vista machine. Can I do this with VB4.0 16 bit
| programs or am I going to be looking at a ton of other issues?
|
| 3) After we get them at least functioning on Vista, we want to
| obviously upgrade them. What's the best route to go? We have to
| decide what programming environment to invest our time/energy in. The
| link above makes me question continuing on the VB.net journey (which I
| haven't even looked at in 4 months because of other projects). There
| has long been a thought of making them web-based to greatly simplify
| distribution/updgrades,etc. One of the potential negatives would be
| the requirement for internet access (often the reps are traveling
| pretty remotely) and/or speed of internet access. What helps you
| decide to go web-based vs stand-alone application? What positives/
| negatives should I be aware of?
|
| If we send them out as a stand-alone application, what language should
| we consider developing them in? Obviously we don't want to go down a
| road that ends up being a dead end in the near future.
|
| Unfortunately with my limited hours, I haven't been able to keep up on
| the trends in programming. I'm trying to get a feel of what avenues I
| should explore. In advance, let me thank anyone who provides a bit of
| insight into this murky situation.
|
| Sincerely,
|
| Jmar
|
| P.S. Please don't go into a discussion about how the client should
| spend more money or hire someone full-time, etc. Budget constraints
| have dictated many of their decisions and will continue to do so. The
| programs have been sufficient to get by with and many of their reps
| are always behind when it comes to technology at the latest hardware/
| software.
|

Also, another personal opinion...dump the Sheridan crap. It's garbage...and
I assurre you everything those controls do you can do yourself with
workarounds if you're into the aupposed "flashiness" the Sheridan controls
used to advertise.

- Kev

"jmar" <jmarzion> wrote in message
news:1050
| Let me apologize up front about the length of this post, but I want to
| get opinions and I need to provide some background...
|
| In the 90's, I worked as an independent contractor and designed a set
| of customized quote generation programs (4 total, one for each product
| line) for a client in VB4.0 16 bit using Access databases. Basically
| the user enters customer information, application information and
| specifies model parameters if desired and the program goes through a
| bunch of engineering calculations to select the best model for the
| applicaiton. At that point the user can select options/accessories
| and a quote is generated in either Crystal Report format or MS Word
| format.
|
| I can't claim to be a great coder, but I managed to teach myself
| enough to get the job done - probably not very efficiently :) These
| programs are distributed world-wide to their reps and therefore used
| on new/old computers and a range of operating systems. Over the years
| we worked out any bugs/issues as they popped up and the programs were
| quite reliable.
|
| Around 2001, I pursued a lifelong dream of becoming a teacher and cut
| back my programming hours considerably (8-12 week). After spending a
| year or two maintaining the programs, working on other projects
| (website, etc) and dabbling with the thought of converting them to
| VB6.0, we decided to wait for VB.net 2003. Once that came out we
| started the process of converting them. Much to my frustration, it
| wasn't nearly as simple as Microsoft made it sound and the learning
| curve was STEEP. It didn't help that every time I started to make
| substantial headway, I would be sidetracked by other projects for the
| client. Not a very efficient way to learn a language. In the
| meantime, every year I would update the pricing in the databases and
| send out the VB4.0 programs via CD. I've basically updated only one
| of the four programs to VB.net at this point because everytime I take
| two steps forward, I get sidetracked for a long period of time and
| then have to figure things out again.
|
| Here's where I need your thoughts/input. Over the last year or two
| I've spoken openly with my client about the inefficiencies of this
| arrangement and about my concerns with the potential of the programs
| not to work properly anymore. With Windows Vista, I think we may have
| run into this issue head-on.
|
| Two weeks ago, a rep bought a machine with Vista Ultimate. He
| installed my application programs and we have discovered that any
| labels that were placed on either the SSPanel or SSFrame controls
| don't show up at all - they are basically invisible. Labels on the
| standard panel or frame controls work perfectly. Even more
| interesting is that I asked the rep to walk through the entire quote
| generation process and his initial report is that it seems to work
| fine except the missing labels (I was very surprised to hear that)
|
| 1) Does anyone have any idea what might cause this issue and how I
| can fix it? The easy answer is to convert to standard controls but
| before I go about that (there are a lot of forms using SS controls), I
| thought maybe there was an easier way. Especially because I use the
| SSTab control and that won't be easy to replace in my layout.
|
| Any help would be appreciated. Of even greater interest is your
| opinions on the next topic. While trying to find out a bit about Vista
| compatibility, I came across an article which indicates the VB.net
| 2003 and even VB.net 2005 may not be fully supported by Vista (http://
| www.theserverside.net/news/thread.tss?thread_id=42426). This really
| surprised me and led to a discussion that I need your opinions on.
|
| 2) My client initially wants to just get the programs so they can be
| installed on a Vista machine. Can I do this with VB4.0 16 bit
| programs or am I going to be looking at a ton of other issues?
|
| 3) After we get them at least functioning on Vista, we want to
| obviously upgrade them. What's the best route to go? We have to
| decide what programming environment to invest our time/energy in. The
| link above makes me question continuing on the VB.net journey (which I
| haven't even looked at in 4 months because of other projects). There
| has long been a thought of making them web-based to greatly simplify
| distribution/updgrades,etc. One of the potential negatives would be
| the requirement for internet access (often the reps are traveling
| pretty remotely) and/or speed of internet access. What helps you
| decide to go web-based vs stand-alone application? What positives/
| negatives should I be aware of?
|
| If we send them out as a stand-alone application, what language should
| we consider developing them in? Obviously we don't want to go down a
| road that ends up being a dead end in the near future.
|
| Unfortunately with my limited hours, I haven't been able to keep up on
| the trends in programming. I'm trying to get a feel of what avenues I
| should explore. In advance, let me thank anyone who provides a bit of
| insight into this murky situation.
|
| Sincerely,
|
| Jmar
|
| P.S. Please don't go into a discussion about how the client should
| spend more money or hire someone full-time, etc. Budget constraints
| have dictated many of their decisions and will continue to do so. The
| programs have been sufficient to get by with and many of their reps
| are always behind when it comes to technology at the latest hardware/
| software.
|

"Bob Butler" <noway> wrote in message
news:3704
> Nobody is bitter about any "improvements". People are disgusted with the
> failure to maintain the core language syntax and the lack of any viable
> migration path. Keep trying, someday you may get it.

Maybe one day you'll get the fact that the incompatibility is due to the
improvements.

Michael

> Maybe one day you'll get the fact that the incompatibility is due to the
> improvements.

Not exactly. After all, they've worked around some of the previous problems
in VB 2005.

I also read recently that somebody started delving into the pseudo-code
VB.NET generates and discovered that there was absolutely no reason for most
of the limitations imposed in VB.NET. According to him, the programmers of
VB.NET were C programmers, and simply had no appreciation for the language
and what was important to developers and what wasn't. It's only as users
have complained that MS has become aware of what some classic VB'ers
consider to be critical issues.

That was his story, anyway. I don't know how much of it was fact and how
much conjecture, but it certainly sounded like a plausible explanation of
why VB7 changed so much from VB6, and why some consider it to be basically
C# with different keywords.

My take on it is that incompatibility is NEVER an improvement. An
improvement that causes incompatibility is dubious at best, poor programming
or a failure to understand the language at worst.



Rob

"Robert Morley" <rmorley> wrote in message
news:2452
> Not exactly. After all, they've worked around some of the previous
> problems in VB 2005.
>
> I also read recently that somebody started delving into the pseudo-code
> VB.NET generates and discovered that there was absolutely no reason for
> most of the limitations imposed in VB.NET. According to him, the
> programmers of VB.NET were C programmers, and simply had no appreciation
> for the language and what was important to developers and what wasn't.
> It's only as users have complained that MS has become aware of what some
> classic VB'ers consider to be critical issues.
>
> That was his story, anyway. I don't know how much of it was fact and how
> much conjecture, but it certainly sounded like a plausible explanation of
> why VB7 changed so much from VB6,

Sounds like complete rubbish to me. I don't see why the IL has any bearing
on it at all.

> and why some consider it to be basically C# with different keywords.

I think it's the other way around. C# is actually VB7 with C syntax. It's
most definately NOT modelled after C++.

> My take on it is that incompatibility is NEVER an improvement. An
> improvement that causes incompatibility is dubious at best, poor
> programming or a failure to understand the language at worst.

I can't agree with that. Compatibility can be a good thing but it also holds
things back *considerably*. Quite often the best gains are made from
breaking compatability.

Michael

>> That was his story, anyway. I don't know how much of it was fact and how
>> much conjecture, but it certainly sounded like a plausible explanation of
>> why VB7 changed so much from VB6,
>
> Sounds like complete rubbish to me. I don't see why the IL has any bearing
> on it at all.

Wasn't that cited in the original VB.NET as being the reason that some
features couldn't be maintained? I seem to remember it was, though I won't
claim certainty on that.

> I can't agree with that. Compatibility can be a good thing but it also
> holds things back *considerably*. Quite often the best gains are made from
> breaking compatability.

Really? Access hasn't had to break backwards compatibility
since...well...ever, yet it performs fantastically for a local database, and
continues to add features with each release. All the other Office apps are
pretty much the same. The Windows API hasn't broken compatibility
(significantly, anyway) across all 32-bit versions, and has compatibility
layers for 16-bit versions (and of course the 64-to-32 bit layer in the
64-bit versions). But looking strictly at languages, C++ hasn't had any
major breakage since dinosaurs roamed the Earth, nor has Delphi, or HTML,
or...I'm sure if I thought about it, I could go on for a while. So why is
VB "special"?

But let's say there were significant gains to be made by breaking
compatibility, you'll never convince me that things like forcing all arrays
to start with the same base was a *necessary* compatibility break in order
to make VB.NET "better" somehow. I suppose you might argue that it lends to
more structured programming, but if that were a concern in VB, there
would've been a lot of other things removed or altered as well. They may
also have wanted to consider the concept that if they were going to break
compatibility, they should have designed the new language in such a way that
an upgrade could actually do a half-decent job instead of just littering
code with ToDo statements.



Rob