Re: [MI-L] windows variables in MapBasic

[Bo Victor Thomsen]

-------------------
Declare Function GetEnvironmentVariable Lib "kernel32" Alias "GetEnvironmentVariableA"
  (ByVal lpName As String, lpBuffer As String, ByVal nSize As Integer) As Integer

Declare function GetEnvironmentValue (ByVal Name as String) as string
Function GetEnvironmentValue (Byval Name as string) as String

  Dim sValue As String, n as integer

  sValue = space$(1024)
  n = GetEnvironmentVariable(Name, sValue, len(sValue))
  GetEnvironmentValue = Left$(sValue, n)
 
end function

Declare Sub Main
Sub Main
  Note (GetEnvironmentValue ("USERPROFILE") )
End Sub
--------------------------------------

Regards
Bo Victor Thomsen
Aestas-GIS
Denmark


Den 23-04-2014 08:03, Burwood Council skrev:

Does anyone know if you can use windows variables in MapBasic? I want to use the %userprofile% variable so I can store/read files in any particular users "C:\Documents and Settings\" folder

 

Thanks

--
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Horsbøll Møller]

Could you use the GetFolderPath$() function for this?

GetFolderPath$(folder_id)

folder_id is one of the following values:

• FOLDER_MI_APPDATA (-1)
• FOLDER_MI_LOCAL_APPDATA (-2)
• FOLDER_MI_PREFERENCE (-3)
• FOLDER_MI_COMMON_APPDATA (-4)
• FOLDER_APPDATA (26)
• FOLDER_LOCAL_APPDATA (28)
• FOLDER_COMMON_APPDATA (35)
• FOLDER_COMMON_DOCS (46)
• FOLDER_MYDOCS (5)
• FOLDER_MYPICS (39)

Peter Horsbøll Møller

Pitney Bowes Software

---

Date: Tue, 22 Apr 2014 23:03:25 -0700
From: burwoodc...@gmail.com
To: mapi...@googlegroups.com
Subject: [MI-L] windows variables in MapBasic

[Bo Victor Thomsen]

That's being an old MapBasic fart like me: You believe,that MapBasic still is at version 4.5 ;-) . My method works, but you should probably use Peters solution if you have a new-ish version of MapInfo/MapBasic.

On the other hands , my method is more general, as it can read any environment variable.


Regards Bo

[Peter Horsbøll Møller]

Nice one, Bo!

Peter Horsbøll Møller

Pitney Bowes Software

---

Date: Wed, 23 Apr 2014 08:48:13 +0200
From: bo.victo...@gmail.com
To: mapi...@googlegroups.com
Subject: Re: [MI-L] windows variables in MapBasic

-------------------
Declare Function GetEnvironmentVariable Lib "kernel32" Alias "GetEnvironmentVariableA"

  (ByVal lpName As String, lpBuffer As String, ByVal nSiz e As Integer) As Integer

[Lars I. Nielsen (GisPro)]

I wonder what will happen to these windows calls when PB/SW launches MapInfo 64 bit ?

Will MapBasic still be able to run in a 32 bit compatable environment ??

Best regards / Med venlig hilsen
Lars I. Nielsen
GIS & DB Integrator
GisPro

[Peter Horsbøll Møller]

That's a good question, and I'm not sure I have the complete answer to that.

A few things I can however say:

- if your MapBasic application isn't using any dll's, system or custom built, your application should be able to run on Mi Pro 64 bit

- if you are using dll's for icons or functions these need to be compiled for 64 bit

I'm sure some of you were also around a few years (probably around 15-20!?) when Windows moved from 16bit to 32bit.

At that time I recall having to deliver all my MapBasic application with two versions of my DLL's: a 16 bit and a 32bit.

Inside the code I then made a check for which to use:

If SystemInfo(SYS_INFO_MIPLATFORM) = MIPLATFORM_WIN16 Then

   '**Oh no, not such an old platform - I don't support that any more

Else

   '**Great 32bit - this is the platform of the future

End if

I guess we will see a need for this check again when the 64bit version of MI Pro is here!

If SystemInfo(SYS_INFO_MIPLATFORM) = MIPLATFORM_WIN16 Then

   '**Oh no, not such an old platform - I don't support that any more

ElseIf SystemInfo(SYS_INFO_MIPLATFORM) = MIPLATFORM_WIN32 Then

   '**Great 32bit - this WAS the platform of the future

Else

   '**Great 64bit - this is NOW the platform of the future

End if

Peter Horsbøll Møller

Pitney Bowes Software

---

Date: Wed, 23 Apr 2014 11:47:19 +0200
From: L...@gispro.dk
To: mapi...@googlegroups.com
Subject: Re: [MI-L] windows variables in MapBasic

[Eric Blasenheim]

Lars, I may not be clear on your question. Probably Peter did but I will put it in my own words.

 

On a Windows 32-bit system you will, of course, only be able to run MapInfo Professional 32-bit and all your existing apps should run including these windows calls

On a Windows 64-bit system running 32-bit MapInfo Professional, you will be able to run all your existing apps including these windows calls.

 

On a Windows 64-bit system running the new 64-bit MapInfo Professional, due to the compatibility of the Windows API, most of these should still run. However, if there is an API change at the Windows end so that, lets say what used to be a 32-bit integer is now 64-bit, your code would have to change to use a new and bigger integer type.

Microsoft has kept most of those things the same.

 

Eric Blasenheim

Pitney Bowes Software

[Glen O]

Using the window API is just a BAD idea. it will not be supported on the next few years.

 

you need to start using the .net framework  http://msdn.microsoft.com/en-us/library/w0x726c2(v=vs.110).aspx

 

The Windows API, informally WinAPI, is Microsoft's core set of application programming interfaces (APIs) available in the Microsoft Windows operating systems. The name Windows API collectively refers to a number of different platform implementations that are often referred to by their own names (for example, Win32 API); see the versions section. Almost all Windows programs interact with the Windows API; on the Windows NT line of operating systems, a small number (such as programs started early in the Windows startup process) use the Native API.^[1]

Developer support is available in the form of the Windows Software Development Kit (SDK), providing documentation and tools necessary to build software based upon the Windows API and associated Windows interfaces.

The Windows API (Win32) is implemented in the C programming language^[2] and is not object-oriented. Windows 8, while still providing the Win32 API, also provides the WinRT API which is implemented in the C++ programming language^[3] and is object-oriented by its design.^[3]

[Thomas Bacon]

I’m not sure that’s true Glen. I’m pretty sure the .NET Framework acts as more of a wrapper when it comes to the WinAPI. It certainly does not replace it.

 

Tom Bacon

GIS Engineer, Mouchel

T 01444 472380 │ E thomas...@mouchel.com │ W www.mouchel.com

Our values: innovation │ excellence │ integrity │ responsibility

--

--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mouchel Limited (Mouchel) is registered in England and Wales with registered number 01686040 at Export House, Cawsey Way, Woking, Surrey, UK, GU21 6QX.  The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. Any views or opinions expressed in this e-mail may be solely those of the author and are not necessarily those of Mouchel. No contracts may be concluded on behalf of Mouchel by means of email communications. Mouchel reserves the right to monitor and intercept emails sent and received on our network.

[Thomas Bacon]

With regard to WinRT (and I don’t want to start a debate, simply pointing this out)…

 

AFAIK WinRT is not a replacement for Win32. That would imply to me that Win32 would be ‘gone’, but I expect that WinRT will in fact sit beside Win32 for the foreseeable future. Win32 may eventually be phased out, but I can’t see that happening for quite a few years yet. So, unless you’re writing applications that you expect to still be used and in circulation in 10+ years time then I don’t see this being a problem for now. I’m pretty sure MS would be making people aware if Win32 was imminently going to disappear.

 

I’m all for using .NET, and I find that I’m more productive if I do, but that’s not to say that you can’t use the WinAPI if you prefer.

 

Tom Bacon

GIS Engineer, Mouchel

T 01444 472380 │ E thomas...@mouchel.com │ W www.mouchel.com

Our values: innovation │ excellence │ integrity │ responsibility

 

From: mapi...@googlegroups.com [mailto:mapi...@googlegroups.com] On Behalf Of Glen O

Sent: 24 April 2014 14:51
To: mapi...@googlegroups.com
Cc: L...@gispro.dk

--

--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bo Victor Thomsen]

Nice to have a discussion with people who are secure in their beliefs.

I wouldn't hazard a guess about how long .NET will exist - but I'm certain (meaning: Very secure in my belief ;-), that the Windows API won't go away for a very, very long time. You can't simply begin to imagine the humongous mountain of Windows based code, that still is dependent on the WinApi, including Microsoft's own office products, the OS itself - and a gazillion different applications, including MapInfo.

Using .NET in conjunction with MapInfo is nice, but not absolutely necessary.  It has been possible to call external functions and programs from MapInfo using plain C or Delphi since ver. 3-4 ? (I can't really remember)  

Regards
Bo Victor Thomsen
Aestas-GIS
Denmark



 


 

Den 24-04-2014 15:50, Glen O skrev:

[Glen O]

http://tirania.org/blog/archive/2011/Sep-15.html

 

this explains it better  

 

You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store.

You can still do whatever ugly hack you please on your system. It just wont be possible to publish that through the AppStore.

Finally, the .NET team has taken this opportunity to do some spring cleaning. mscorlib.dll and System.dll have been split in various libraries and they have moved some types around.

 

[Bo Victor Thomsen]

Contact me the day MapInfo is a "Metro"-only based application and is sold through the Microsoft appstore. And when all extensions to MapInfo must be sold through the same appstore. This will probably make me programming 100 % on QGIS instead. But I suspect, I will be retired long before this Microsoft "wet dream" scenario is in place.

Just to reiterate: Using .NET to program MapInfo extensions is nice but not totally necessary. You can still and for the foreseeable future make extensions using C or Delphi. And if your customers still are using MI 8.5 or earlier (Which a lot of users still do) this is the only way to make dll based MapInfo extensions.

Regards
Bo Victor Thomsen
Aestas-GIS
Denmark

[Glen O]

this is my point of view on this topic .

 

I use vb.net 2010 & now 2013 to control mapinfo v10 I have nothing but problems trying to make it work.

and keeping it working after Microsoft updates.

 

the problem is the mapinfo corp does not follow good program practices or more accurately they do not update their software in a timely fashion.

 

 then their is the crazy 16 bit STUFF LEFT OVER in mapinfo

ie 16 bit hex colors passed to mapinfo you have to convert down from 32 bit windows colors to run

 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384249(v=vs.85).aspx

 

and then this nightmare of how to format a command to pass to MapInfo

Dim temp As String

temp = "run application" & Chr(34) & "C:\OCG Data\MapInfo Mapbasic\Sector Maker\test.mbx" & Chr(34)

mapinfo.Do(temp)

 

ask your self why can't I have long table names? or multi file input on MB?

 

winRT and windows API are not the same and handle calls based on bit size

windows API can handle a 16 bit call windows RT can not

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384249(v=vs.85).aspx

their is no windows API on windows 7 & 8 only winRT that handles the API request

a problem that mapinfo currently has on all versions

 

if you write a multi thread software that talks to mapinfo and you try and use windows API calls you will find you quickly have major issues 

 

if you want to write stable software stay away from windows API calls, anything that can be done by not interface with mapinfo software should be handled by the calling software  ie use net calls the system will handle any threading issues.

 

again just my point of view  

 

 

 

 

[Bo Victor Thomsen]

Glen -

This is something we can agree on - MapInfo Corp. and later PB deserves a good thrashing for not making MapInfo a "real" windows program and not do some real spring cleaning in the sourcecode. MapInfo for Windows started out as an application that could run on both Windows, Mac and Unix using an interface technology which worked on all three platforms with a common OS independent core. Hence the MapInfo "not quite correct" Windows user experience (i.e weird user dialogs and other stuff). The Unix and Mac support was ditched rather early, but MI Corp. didn't rewrite MapInfo for 100 % windows after this (And I suspect they still haven't).  The missing rewrite is probably the real culprit when problems with threading and inter-process communication occurs. Somewhere deep down in the belly of MapInfo sourcecode there still is the original - single threaded - state machine, that control process flow inside MapInfo.

But that's not the point ;-)

The point(s) is:

• The Windows API won't disappear from Window for a long time (At least the lifetime of Windows 8)
  
  
• When the Windows API is removed from Windows (9-10-11 ??) MapInfo - and a gazillion other programs -  must have had a total rewrite. This would probably deprecate/retire MapBasic from MapInfo a long time before the disappearance of the Windows API from Windows, making this discussion a moot point.
  
  
• As long as MapInfo .NET is a very thin wrapper on the - ancient - MapInfo OLE wrapper - which essentially only have two methods "do" and "eval" - there is no real value using .net instead of older technology like Delphi. Further, you are limited to calling static methods in .net from MapBasic, essentially reducing c# to a functional language. 
  
  
• I would never, ever try to do multi-threading directly from MapBasic. It is not possible. This includes calling loads and loads of windows api functions with callback functions and strange pointers to memory. But other windows api functions behaves nicely from the MapBasic environment.
  
  
• On the other hand, multi-threading can be done from both Delphi and from .NET MapInfo extensions. It's a matter of convenience and what you are comfortable with. Use .net if you like C# or VB. Or use Delphi if you like Pascal.
  
  
• Actually I use .NET myself when writing add-ons to MapInfo that uses multi-threading, because Visual Studio and C# makes it darn simple to create a Form and add a BackgroundWorker component to the dialog form.
  But doing other stuff, I use Delphi, because I use some Delphi components not available as .Net components. And when doing pre-MapInfo 9.0 stuff, the only option is Delphi or C.      
  

And to All that reaches this part of the message without falling asleep or vomit, have a nice weekend. 

Regards

Bo Victor Thomsen
Aestas-GIS
Denmark
 

--