|
So
the mystery at this moment, I guess, still remains. I offer
some insights passed to this list in Sept 2004 by Eric Blasenheim with MapInfo..
I asked a question about how .COM can be used by .NET generally. Well,
.NET supports COM entirely – that’s not the problem. The “problem”
– if any exists (and I cannot imagine that MapInfo Corporation would
allow this situation) is whether a substantial proportion of the latest
incarnation of MapBasic coding would be interpreted and executed within the new
.NET product. And that
would imply backwards-compatibility of older MBX equivalent to that possible
now with (say) v8.0 – ie, can an MBX that was created with a MapBasic that
supported only MapInfo Pro v6.0 features now work with MapInfo Pro v8.0? I
would say yes. And so I would expect that same MBX to work with the new, .NET
version of MI. IL Thomas From: Neil Havermale
[mailto:[EMAIL PROTECTED] Jaques -
My
understanding based on, gosh almost two years now of running rumor-ology,
is that MapInfo is going to great lengths to insure that those with MapBasic
investments are reassured that their MB legacies will remain compatible with
the emergence of a MapInfo desktop offering (Professional ?) based on
.NET technology, i.e. MapXtream 6.+? I get the
feeling that your MB-future’s insight at the moment on this unqualified
defacto promise is suggestive of “Yes, we have no bananas”? I
understand that at the recent Users Conference just last week there were
several sessions dealing with this issue. Has something significant changed? So
the mystery at this moment, I guess, still remains. I offer
some insights passed to this list in Sept 2004 by Eric Blasenheim with MapInfo..
I asked a question about how
.COM can be used by .NET generally. Possibly
others can share their insights of this grand project? Neil My question on MapInfo-l
in September 2004 ….. From our software
engineers I have been told that there may be some sort of intermediate step
that essentially puts a .NET-wrapper around WIN32 code permitting such legacy
code to be used in the NET environments? Is this a safe and reliable
"first move" for legacy code or is this more like buying re-treaded
tires? They look great on the rack, have a low cost, but tend to fly
apart under stress and fast speeds. MidNight Mapper Aka neil
Neil .NET wrappers are totally
acceptable. In fact, .NET does some of them for you. There are three ways
of interoperating with native code. They use the term native rather than win32
because you can also call 64 bit code and potentially any other code (linux) on
the platform you are running. There are performance issues in each of
these mechanisms and Microsoft is changing them as we speak. The simplest is called
PInvoke. It allows .NET code to call an entry point in a .DLL. This is
essentially what VB programmers have been doing for years and conceptually
similar to what we do in MapBasic calling a DLL. Using a .NET concept called
attributes, you can control a few things better such as calling conventions and
how data is converted or "marshalled" from .NET to the native
DLL. The .NET framework uses this facility itself to call Windows
APIs. The calling is one way (.NET to DLL) COM objects can be called
from .NET by the building of wrappers. The RCWs (Runtime Callable Wrappers) are
built automatically by Visual Studio when you tell it that you want to use a
COM object. The dialog in Visual Studio where you select the objects that you
want to reference has a TAB for .NET assemblies as well as COM objects. The
wrapper handles the calling of the COM objects and marshalling of data.
MapInfo distributed a wrapper like this for those who wanted to get started on
.NET work over year ago. The wrapper handled the older MapX/MapXtreme. Connected with that
technology is the ability to call a .NET Code from COM. These wrappers are called
CCW (COM Callable Wrappers). Check out MSDN for some
good papers or http://www.codeproject.com/dotnet/COM_DOTNET_INTEROP.asp. The third technology is
the C++ compiler. The .NET version C++ compiler supports what is called Unmanaged
(native) and managed (MSIL) code generation. You can build totally MSIL code in
C++ if you wish. The interoperability to native code is built into the compiler
with a few rules that you have to follow. It is so easy to do that they called
the technology IJW (It just works!). Well, we found a few problems with that
technology. However, it is improving and some of the things they are doing in
the next version are pretty amazing if they work. We are looking at that now.
Note from my earlier memo that just because code is MSIL and compiled to native
code by the run time (Just in time) compiler, does not mean that the code is
"safe". MapInfo uses this C++
technology to interoperate between it's public interface code (MSIL) and the
native code. Hope this helps. Eric Blasenheim Software Architect MapInfo Corporation From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jacques Paris It may seem
strange that in the present context where the future of MapBasic applications
is rather threatened by all the rumours of the abandonment of MapInfo.COM to
the profit of a NET version incompatible with MB I am still writing MB
applications. You have to imagine that I foresee despite all those rumours
there will always be a niche for the “old” users, that there are
still pressing need for new tools, that if I do not consider at my
“age” learning a new language, practicing an old one has many
“mental” benefits and brings more immediate satisfactions (since I
accepted there was no $ rewards to expect for that activity). After that spiel
some may take as a “testament” but is more like an act of faith,
here is what I can offer you. DateStringConvertor
reads in dates as strings in different formats and convert then in strings
respecting certain rules (only digits, leading 0 present, sequences DMY, MDY or
YDA, separator space, - / .). There are probably 2 main reasons for using it:
to convert “foreign” entries to a “standard” format or
to prepare non conformant date formats to one that can be used by MI for
converting date strings to date variable. MI allows only two kinds of format in
the stringtodate() function, “US” and “local”, the last
one being defined by the particular Windows regional settings. One could of
course play with those settings to match the date input format but it seems
rather awkward and dangerous. DateStringConvertor avoids that and allows for
two different “spellings” for month names that the user can alter
(in the INI file, with all the language strings as that app is Multi Lingual
Compatible) to match his needs You will find
it at www.paris-pc-gis.com/download.htm
in the MLC project. Hoping that
app could be of help to some of you, like it has been to Terry MacDonnell ( Jacques Paris |
_______________________________________________ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
