Hi !
I have a few remarks on Bill's and Thomas' mails:
Another nice way in creating MapBasic Code is using
the Visual Basic Editior.
This offers some really nice features, where MapBasic
leakes:
- You can organice your projects with it.
- you can perform search and replace operations over more
than one module.
- you can save all your modules at once.
- and of course you can use the Basic-Syntax checking
- THe code is nicer to read since different colors are used for
comments and so on. And all MapInfo comands will apear in red
since they are not part of Visual Basic, but this makes it easy to
identify them at one view.
Visual Basic inserts a line in the start of each module which has to
be removed before compiling in MapBasic, but it would be
possible to write a small makro which does this for you. (Maybe
we will write one in the near future...)
Overall I agree with Thomas that MapBasic has not changed
a rather long time, and it should really offer more user friendiness
especially for creating Dialog boxes.
Yes, MapInfo should not write editors - the wheel need not to
be reinvented. But what MapInfo Corp. should do is not to sleep in
this regard. Maybe they can buy some editors in order to
incorporate them into their product, or talk to some guys in
the huge MapInfo community who have already written
some nice tools for enhancing the ablity for creating dialog
boxes.
There is another general point which I do not really understand.
MapInfo seems not beeing able to manage the large amount of
MapBasic add-ons efficiently.
For example there exists a bulk of routing applications but
it is for a user difficult to choose one of them which suits their
needs best. There are no standards, ES.. offers ONE routing
application which is sold under their brand and marketed all over
the world. MapInfo should do so, too either by buying the best
of already existing one or be installing some certification
procedure which grants a user that this application will work
well with MapInfo and commonly used data.
There are a few applications where this works well - I guess to
the benefit of both parties. (Vertical Mapper i.e.).
I am looking forward to hear the opinion of other list members
concerning this isue.
Karl Zeiner
AGIS GmbH, Linke Wienzeile 4, 1060 Wien
Tel: (+43-1) 5879070 Fax:(+43-1) 587907079
email: [EMAIL PROTECTED]
-----Urspr�ngliche Nachricht-----
Von: Bill Thoen [SMTP:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 24. M�rz 1999 21:11
An: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Betreff: Re: MI MapBasic and Security
A limitless editor? No too likely! Sadly, 64K is the limit for
the MapBasic editor (but the compiler can handle much larger
files--you just have to use another editor to create them). Also
if you want to use the "Find" function in the MB editor, it will
not see anything beyond 32K. But I've never seen it be so rude as
to rewrite all your existing code into Gibberish++. That seems
extreme and ought to be classed as a serious bug. When I've hit
this, it just lost the stuff I typed since I last saved. Coding
is like technical climbing in some ways; you need to set
protection and clip in as you go. But if you sit down and just
type from byte one to the end of the program without saving as
you go (free-soloing), one day you'll make a nice big crater. And
sometimes, even you if are careful, the equipment fails and you
take a screamer anyway.
The workaround is to break your modules up into smaller pieces
and either use the "include" directive to allow the compiler to
build them or compile them as separate modules and link them.
You can also edit code in a real editor and use the "compile from
file" and "link from file" options in MB. With a good editor that
has macro capabilty like PFE or even Word, you can really
decrease your development time and even write better code. I
don't think MapInfo should waste time building editors--they
should stick to mapping-- because nobody could ever top vi... ;-)
- Bill Thoen
Thomas G�lden wrote:
> Dear List,
>
> I have experienced the following today: In a large module, I
> added some code
> and suddenly no further keys were accepted. So I closed
> MapBasic and
> prompted the question if I want to save the changes with yes.
> Next I tried
> to open the file again and it appears empty. The file size
> although is still
> 64K. Opening the same file with a text editor revieled that all
> text was
> overwritten with one of these rectangles. That probably means
> the file is
> gone, MapBasic kind of crashed when attempting to save.
>
> Then I remembered that sometime ago on the list somebody
> mentioned a certain
> limit of the file size the MapBasic editor can deal with, and
> so I think it
> was that limit which caused my file to become corrupted. Well,
> first I want
> to ask the list if somebody knows, if I can recover that file
> somehow. I
> have an older version, but I have made some important changes
> that I would
> like to recover.
>
> Then, of course, I want to complain. If my suspicion about the
> reason for
> the crash is correct, then I think this kind of ungraceful
> dealing with such
> a size limit is totally inappropriate. There should be a
> warning message at
> least, and it should be possible to safely save your work.
> Additionally it
> is very poor that this size limit is not documented very
> obviously (at least
> I am not aware of). To have a MapBasic module with about 2800
> lines of code
> should not be that unusual so that this might have quite often.
> Now I know
> that I have to split my code even more. My App already consists
> of six
> modules and becomes quite difficult to manage now.
>
> Which brings me to the second point. Although MapBasic is not
> the most
> modern compiler of the world, it is still quite required and,
> by the way,
> the syntax of MB is really easy to learn as opposed to ESRI's
> Avenue. What I
> do not understand, however, is why MapBasic has not get any
> overhaul since
> such a long time. The development environment is really
> primitve and large
> projects are difficult to manage. There are no Visual Tools not
> to speak of
> data aware controls, which would be a very good enhancement to
> construct
> dialogs for data entry. The size limit of the compiler is
> inappropriate also
> and at least MapBasic should keep a backup file in the
> background (maybe it
> does ???) in case you crash like I did. Also in large modules
> the search
> function of the compiler cannot find items towards the end of
> the file.
>
> OK, there is MapX, but not all problems are best served with
> integrated
> mapping, especially if the client wants to use the standard
> MapInfo
> interface at the same time.
>
> So, I would like to encourage MapInfo to enhance there nice
> MapBasic
> language to a tool, what MapInfo Professional really deserves.
> If the reason
> for the crash could not be the size limit I would like to
> sincerely
> apologize for my critics, but at the moment I cannot think of
> any other
> reason. The points about necessary enhancements should be valid
> anyway.
>
> What does the list think about all this ?
>
> Regards
>
> Thomas G�lden
> Diplom-Geologe
>
> Email (privat): [EMAIL PROTECTED]
> Email (dienstl.): [EMAIL PROTECTED]
>
> ------------------------------------------------
> ---------------------
> To unsubscribe from this list, send e-mail to [EMAIL PROTECTED]
> and put
> "unsubscribe MAPINFO-L" in the message body, or contact
> [EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
