Accessing a VB.NET executable from VFP

[jpower69]

I hope that this is the correct forum for this.

I already have a VFP function that pings a sql server running within a VFP executable

I was asked to see if I could create a VB.Net executable that does the same thing.but have that executable called from the VFP application.

I need to know if I should use something like shellexecute(), which I used about ten years ago to access crystal reports 2012 from
a vfp application or if there is a better way..

If so, can I get some guidance on what to set up the shellexeute or another method to accomplished this

Thanks in advance for any comments, suggestions

 

[Olaf Doschke]

Well, not much changed in running an exe, so ShellExecute is still fine, you could also RUN /N some.exe

If you need to wait for the VB.NET EXE to exit and need to get the exitcode, which indicates the existance of the server, you need something else, as shown here:

http://fox.wikis.com/wc.dll?Wiki~ProcessExitCode

There are other ways to let VFP know a result, though. It's up to you as the developer how the VB.NET EXE will work. Perhpas easier would be an assembly you use via dotnetbridge:

http://west-wind.com/wwDotnetBridge.aspx

Bye, Olaf.

 

[jpower69]

thanks you for the fast response

greatly appreciated

 

[jpower69]

i have a follow up to using the shellexecute

How can I get a return value
I know the process works, I am able to ping the server,

but I need to know how I can get a return value when the ping process fails
here is my statement

DECLARE INTEGER ShellExecute IN shell32.DLL ;
INTEGER hndWin, ;
STRING cAction, ;
STRING cFileName, ;
STRING cParams, ;
STRING cDir, ;
INTEGER nShowWin

**

cAction = "open"
cFileName = "c:\temp\ping_servers.exe"
cParams = In_Params
cPath = "c:\temp\"

mRtn = ShellExecute(0,cAction,cFileName,cParams,cParams,1)

I need to check the value of mRtn

any comments/suggestions greatly appreciated

Thanks in advance

 

[Olaf Doschke]

You can't using ShellExecute.

See my first answer, in case you need the exitcode. I referred to

http://fox.wikis.com/wc.dll?Wiki~ProcessExitCode

already there.

Bye, Olaf.

 

[jpower69]

thank you again for the fast response

greatly appreciated...

 

[Olaf Doschke]

What you need to do in VB.NET is to set Environment.Exitcode = returnvalue before you quit. Envornment.Exitcode is a static member, so nothing else is neede, just an Imports System, which you should have anyway.

Bye, Olaf.

 

[jpower69]

thanks

I'll give it a try and let you know

 

[clipper01]

If you need to use dotNet, definitely the best way is to use wwDotNetBridge ( free from

http://www.west-wind.com

) This is a superb way to link the power of dotNet to Foxpro, great for any system/net utilities, working with XML etc, once you have your first little app done , you will find many other uses for it

1) download and look at the examples
2) for your requirement , you then build a small net class library , e.g. Fox2Net.dll ( your post said you were asked to use an executable, not sure why , maybe the 'asker' just meant to use a dotNet 'method'.
3) the 'ping' code will be like ( this is C# but VB will be similar )

public string PingServer()
        {
            Ping  p1 = new Ping();
            PingReply res = p1.Send("google.com");
            if(res.Status.ToString()=="Success")
            return "Success in " + res.RoundtripTime.ToString() + " ms";
            else 
            return "Ping failed";
        }

4) the Foxpro side will be something like , it loads the dotNet dll , calls the PingServer method

Do wwDotNetBridge
Local loBridge As wwDotNetBridge
loBridge = Createobject("wwDotNetBridge","V4")
loBridge.LoadAssembly("Fox2Net.dll")
loFox = loBridge.CreateInstance("Fox2Net.Main")

? lofox.PingServer()

 

[Olaf Doschke]

Yes, I pointed to that already, too.

One of the simplest things to do is to call static methods or core .NET runtime libraries, as Rick shows:

loBridge = CreateObject("wwDotNetBridge","V4")
? loBridge.InvokeStaticMethod("System.Net.NetworkInformation.NetworkInterface",;
                              "GetIsNetworkAvailable")

No assembly is loaded in this case.

Also see thread184-1734668

Bye, Olaf.

 

[clipper01]

Olaf , read your post , so we are both cheer-leaders for dotNetBridge . I don't think it would be ideal for 'migration' of apps ,it is more suited to adding 'new capabilities' to VFP. With the proven tests of VFP working with Windows 10 , it is becoming all the more apparent that this is a viable route.

here are some that I can suggest
1) getting any kind of system/net status e.g. the ping example above , any kind of file handling/watching etc
2) working with any kind of XML beyond the very basic cases that VFP handles
3) linking to other assets of a modern business e.g. SharePoint , Exchange Server ( does a lot more than just linking to an Outlook client)

regards , sean m

 

[Olaf Doschke]

I don't understand why you say "read your post". Did I contradict myself with things I said there and here?

You're right that dotNetBridge can be used to extend VFP, but I see no use in our (german) economy to use a deprecated product. The situation of migrations is unavoidable and there are many opportunities to earn money and get jobs, if there weren't people who still stick with 2.6 DOS apps and don't see the similarity of value loss of hardware and software, depreciation and amortisation.

What I see, when customers migrate is bad, too though. Innovation stop of old software and reimplementation or changing towards standard software. I see a way to have a zero day benefit of changing an app to hybrid and that starts in adding new features in dot net code, to move data to sql server, to change functionalities to services, to use com interop to iunclude .NET forms in a VFP app. Instead they make a big leap that takes much longer and makes them stand still for years. It's nonsense in my eyes, not only in regard of technology, also economically. It only works, as long as their competition makes the same error.

The need is there to have service contractors knowing the new and future development world. As long as it's done the way it is done, as you can't afford old and new service contracts you have no collaboration and things are lost in reimplementation. I see customers not even knowing their own business rules. they are in their applications and not documented in use case documentation, UML diagrams. Consultants asked to replace inhouse applications are starting from scratch in regard of such informations, though there should be documentation available for them just to read requirements. So there is bad information and knowledge management.

Money, which goes for consultants is not there for further development, so that contributes to the bad situation.

Overall I don't see VFP winning and staying, because all this fails, no, companies change towards .net developers as outsourced or employed developers. The old applications are merely taken as blueprints in regard of UI and what users know about them. And .NET developers underestimate the need to understand VFP and it's concepts and overestimate the power of .NET to easily migrate everything. The result again is loss of information and functionality or projects not finishing in time.

The code you can call via dotNetBridge can be reused later when moving forward to a 100% .NET solution and this is the way I intend to use this and other interoperability features to move from VFP. So, my view on the use case for the dotNetBridge differs from yours. I don't misunderstand the potential, I just don't see a core of VFP staying the same will move on to become a VFP10. Even though we've already seen a 64bit VFP, it's not where I would go, not even for my private use.

What I see as the biggest problem is the unawareness of business deciders and budget responsible people of customers for other ways of migration. The rather ask MS for a migration path and get no or uncomplete or inadequate answers, so they only see a reimplementation or move to other already more modern or standard software. Evolving applications hybrid is possible, if you accept to stay in Winforms, you may even blend together wpf forms in a VFP app and since Windows 10 brings win apps on the desktop that would also be an option. Even cloud parts can be integrated. The UI look and usability can be levelled to a common denominator and you can advance that once most of the applications have moved to .NET. The main advantage is users can profit from enhancements directly and don't have to wait for the new application landscape to be fully done.

Bye, Olaf.

 

[clipper01]

Olaf , you misunderstand , this is caused by the strange habit of the English langauge having the same spelling for the past and the imperative tense. I am sure this could not happen in German

So, when I said "Olaf , read your post" , I did not mean " Olaf , get out there and read your post " , I meant " Olaf , I have read your post"

I was actually paying compliment to your post. I'm not against migrating to dotNet, in fact I've migrated several of my apps to dotNet. The reality, though, is that with one or two exceptions, there are no members of this site who have made ( or will make ) the time investment to go this route, all you see on this forum is " great , VFP will work for another 10 years , by which time I will retire ".

So I'm just pointing out that with a pretty minimal grasp of dotNet , you can ADD a lot of very valuable functionality to VFP apps e.g. links to Sharepoint , Exchange Server , XML handling , links to Office 365 etc etc . It does not have to mean a " migration " to dotNet

So wwdotNetBridge is a great way to improve our clients VFP apps and hopefully encourage the further moves to dotNet


regards , sean M

 

[Mike Lewis]

this is caused by the strange habit of the English langauge having the same spelling for the past and the imperative tense. I am sure this could not happen in German

Oh heck. I'm fighting an overriding temptation to point out all that's wrong in the above statement. I really want to tell you that the imperative is not a tense (it's a mood); that your point about the same spelling applies to the present tense not the past tense ("read" is a bad example because it is one of the few verbs that are the same in the past and the present; consider instead eat your vegetables compared to you eat your vegetables); and any misunderstanding on Olaf's part was not caused by any quirk in the English language, but because you omitted the subject of what would otherwise have been a clear and correct sentence (I read your post).

Those are the points I want to make, but I will fight against the temptation. In fact, I won't say any more about it, I'll just

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clipper01]

Possibly veering off track here, not actually a tek-tip , but fyi

The imperative tense in English is used to give an order, a warning, an appeal, an advice, a suggestion, an instruction and in some cases a request to another person, to a group of people or to animals. It is very easy to form the imperative sentence: Simply take the verbs' infinitive form (without the "to" infinitive indicator).

all best

 

[Mike Lewis]

The imperative tense in English is used to give an order, .... etc

The third word of that quote is wrong. It's not a tense, it's a mood. Tense is to do with time (past, present, future). Mood is to do with attitude or intent (give a command, ask a question, state a fact, etc).

I'd better shut up now or I'll ruin an otherwise excellent thread.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

It's OK for me, too.

Yes, I was rather reading that as imperative, not as short for "I read your post". The rest was my wrong interpretation. It didn't hurt to describe my experiences and opinions, though.

Of course Rick intended the bridge to expand the possibilities of VFP, as far as I know this was made to enable the web service proxy generator. It's all useful whether you stay VFP or use it on the path of migration as a first step to expand and develop in the .NET world.

Bye, Olaf.

 

[clipper01]

My vote also , done deal , Olaf has made an excellent summary of the practical case for migrate/dont-migrate ( dotNet /dotNot ? ) , nothing wrong at all with the stick-with-vfp approach , yet have to be ready when the customer demands it , and this will inevitably start to happen .

 

[DSummZZZ]

dotNet /dotNot

Or is it dotNet / don'tNet?


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm