"Neil" wrote in message
Maybe when I'm completely done with the VBA I'll look to port it to the
macro language. That seems like a better idea than tweaking &
troubleshooting in the macro language.
The above is what I done in the past. In fact, my Tic Tac Toe game, I
got the code working in VBA first, got the bugs out, and THEN converted
to macro.
Hey, just thought of something. Someone could make a fortune writing a
program that converted VBA code to macro code! Would be rather tricky; and
the VBA would have to be in a certain format, I'd assume. Still, I'd buy a
copy of that software!! LOL
The problem is you're dealing with different architectures, it's the
difference between a good quality heavy duty trucks, and that of aircraft.
Aircraft are lighter weight, use more expensive materials, and big heavy
duty bench seats, or large diesel engines don't work well for Aircrafts.
We could for example come up with the idea of placing helicopter blades on
airplanes, write this up and tell Boeing we've just come up with a brilliant
idea how to eliminate the need for airports.
The problem is for those database triggers, you don't have a message box
command, you don't have record sets, you don't have global variables, and
the list goes on and on and on.
If you give a person the VBA editor they would be so disappointed because so
many things would be so changed. It probably would not be worth the effort
to allow them to continue to use an old VBA editor since then that gives the
SAME expectations as VBA. There would be so many things changed that basic
features of the language would not exist anymore.
We never saw a converter from VB6 to vb.net, And the reason was the
architecture change.
We don't have record sets in a web form And last time I looked the safari
web browser running on your right pad dozen have support for those
recordsets. The trek and problem is, you won a system in which you can write
some code that eventually runs on the user's desktop or not ?
This is highly ironic, given that, not too long ago, Microsoft tried to
kill
the Jet engine and replace it with "SQL Server everywhere." Like so many
Microsoft ideas-du-jour, it failed miserably. But I find what you write
above highly ironic, given the direction that Microsoft tried to go in.
I don't believe they tried to kill jet. In fact by access 2003 they'd
already listened to the developer community, and DAO had returned as the
default data object model after an absence going all the way back to access
97. I mean 10 years in computer history, is an enormous amount of time, and
I can't count on my hands very many tools I've used for longer than 10
years, and we're in the realm of at least 9 years that JET has been promoted
and in fact has been the default data engine for at least the last 9 years
of Access.
So while Access had a fling with ADO, I cannot recall a period in which the
Access JET data engine was being depreciated.
Would it have been easier in t-sql? Yes, I think so. Definitely.
Hum, close call here. I cannot say the functions and ability of t-sql would
have helped much more here, about the only exception of maybe a looping
command .
Here's the thing. The macro language is definitely a great advance over
previous the previous macro language; but it's still clunky to work with.
At least with t-sql you can copy and paste, comment out code, etc. Makes
writing and troubleshooting much simpler.
Well the macro editor does allow cut and paste, and in fact if you hold down
the control key you can drag and drop code and create new blocks, Kind of
something I wish I had in the VBA editor. I mean don't get me wrong, but
part of the problem with an editor is that they had to remain compatibility
with the past macro language.
Furthermore when you're writing code in a WEB form, you need to dynamically
change which expressions and feature sets are available, because some of the
commands are going to run server side with near VBA function set, and the
next line you write will NOT have all those features. Trying to implement
that in a free form text editor would not work all that particular well.
I mean due one editor for VBA (which is common to ALL of office), another
editor for the old macro language, a new editor for the web form scripting,
a new editor for table triggers? That means we up to 4 or 5 editors here!
By adopting a new macro editor, they eliminated at least the need for 3
different kinds of editors here, and this keeps code compatibility with the
previous macro system that's been around for a very long time .
The macro language, though, has the advantage that it uses native VBA
functions. So, theoretically, one could write and troubleshoot in VBA, and
then simply port to the macro language (and keep the original VBA around
for modifications/troubleshooting/re-porting (again - where's that VBA to
macro converter that I can purchase??
)).
As I pointed out, I'd don't maintain the older Phoebe a version of code, but
for testing routines and getting something working, I do in fact were often
write it in VBA.
I mean once the code is up and running, then a few tweaks and changes
generally does not result in in need of debugging or much modifications
anyway .
And you can try my Tic Tac Toe game here:
68.151.51.125:37116/TicTac/default.aspx
UserName fun
Password fun
Very nice!!! Loved it!! And loved your buttons!
Tell me: how did you do the logic? Was that your own logic, or did you find
a "tic-tac-toe engine" somewhere?
I use the following article that laid out a set a pattern matching for the
basic moves:
http://webster.cs.ucr.edu/AsmTools/MASM/TicTacToe/ttt_1.html
I'm ashamed to say that I couldn't beat the computer. Best I could hope
for was a tie. I'm a miserable failure of a human being... :-((
It is true that Tic Tac Toe is boring and simple!
However, I am thinking of extending this idea and next time around I will
build a chess game.
In fact what is quite amazing, is I built the whole game in basically what
amounts to a whole evening, I used part of a Saturday night and Sunday
night, and the whole thing was up and running. I suspect that perhaps a lot
of the VBA developers here would have a hard time building an application in
VBA.
So the trick here is that I used the macro system enough that I understand
exactly what designs will work and what designs will not - This skill set in
fact is far more important than learning the macro language itself !
In other words knowing what designs to avoid, knowing what designs will not
work is just as important here.
And I suppose it helps with past experience having programmed in systems
like assembler since in those systems you're dealing with VERY simplified
sets of commands, and therefore it your software designs and skills that
make up for the lack of functionality in the language you're using.
Everybody's used to say that real programmers are those that write code in
assembler! It turns out that most assembler systems are not much more
difficult than that of using a programmable calculator, The challenge of
assembler is not the complex of the language. In fact assembler is so dead
simple and that is the problem. So it is the reverse in that simple problems
become complex because you're using such a simple set of commands to solve
problems.
I suspect the above a reason is why I had so much success with access web
services, because I have a lot of experience in this industry, and I've used
a lot of systems with even less functionality and ability than access web
services to develop business applications with.
