Can i use api to find a variable Pointer

[ashthud]

In foxpro 2.6 i can pass variables by reference using @; so i know pointer information is somewhere flying about...
Is there an api function or maybe just a standard foxpro THING that i can do to find the pointer (in memory) of my variable?

Maybe its a case of passing my variable to a dll that then returns the pointer(????). Thanks.

 

[DSummZZZ]

Gee whiz dude. You're trying awful hard to rework 2.x. Pushing it beyond what it was really made for.
I'm curious. Why?

Sorry though, I can't answer your question. There may be something in FOXTOOLS. If not, maybe using a windows handle you could get to it with an API.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[ashthud]

When I was doing my Alevels a couple of years ago, one of my tutors was constantly saying "you won't be able to do that in vb6", i believed him until i found solutions on my own...

My company (that i joined @ the beginning of this year) use foxpro 2.6... its such a weird language; SO different from anything i have ever seen EVER...
So anyway, when I was told "there's no feature in foxpro to allow that" i just had to go looking for solutions.

Baring in mind i am almost completely new to the language i have only achieved: trayicon with animated icon, *'s for password input box, tab dialog, and on my way to creating a treeview control with the comctrl32.dll... apart from win32api, ive only used call32.dll and foxtool.fll, im not afraid to use more.

----

Back to my question... I can get the handle of foxpro window using the FindWindowA() function... do you know of any apis that can at least look for the pointer/addressof of procedures?

 

[ashthud]

Oh - another reason for trying to push the boundaries is because i moved from vb6 (a feature-rich language),
to foxpro 2.x (a feature-poor language).

I dont like to be told i cant do something, even if it me telling me i cant do it =P.
Do you feel the claustrophobic-ness of foxpro?

 

[DSummZZZ]

Well, here's the deal. Foxpro 2.x is pretty much an obsolete language. Sure, there is still a lot of 'legacy' code written which is still out there and being maintained (I still maintain an app written in 1993). But there are many versions and upgrades since 2.x, and although the newer versions will pretty much run the old code unchanged, most people prefer to upgrade the apps to take advantage of the newer and better features. The newer versions also handle windows API's quite well.

So if you're looking for a challenge, why not use the time to take on updating older fox apps using the newer and much better Visual Foxpro rather than just doing stuff just because it can't be done?

Just a thought.

However, once again, I don't have a direct answer for your question. You may find that doing a search on these phrases will shed some enlightenment on the inner workings of earlier versions of Foxpro though:
"FOXTOOLS.FLL"
"FoxPro Library Construction Kit"



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[ashthud]

There's nothing more i would like to do than to upgrade to a higher version...
infact, if i had a choice, i wouldn't even be using foxpro.
The company i am with have been using this system for far to long, and the main programmer just prefers it to any of the vpf stuff.

BTW I can't find anything about pointers in the foxtool.dll.
I will have to create a VERY simple dll to return the pointer.
As a temp solution when i have a function that require pointers, i am simply able to send the variable name =S ODD!

 

[ashthud]

IN FACT IVE JUST FOUND THE SOLUTION:

Function: "VarPtr"
Library: "vb40032.dll"
Param(1): <Any>
Return: long

Declare Function VarPtr Lib "vb40032.dll" (x As Any) As Long

Andrew Howell (microsoft.public.fox.programmer.exchange) mentioned that VarPtr is an undocumented feature of VB6...
so i just googled for varptr. Cheers for your help/advice Dave.

PS: i said that my colleague prefers foxpro 2.6, but i think it might just be the case that we haven't got vfp at work;
its just not practical i suppose (i havent the foggiest)

 

[DSummZZZ]

Mike,
California? We have a Stratus 'mainframe' running COBOL and ANSII C code that I am using Foxpro 2.5 as well as VFP 6, 7 and 9 to call functions/applications on, to retrieve data from! (I'm in Las Vegas by the way).
In fact, many large resorts here are still using C, RPG and COBOL on mainframes or mini's.

ashthud,
Glad you found a solution!

Too bad really, that you have old Fox but not VFP. There are many arguments for upgrading that could be presented to the money people in order to upgrade to VFP, but the biggest is the similarity of the language and functionality for updating the applications already being used and maintained in your company.
Whatever 'it' is, if it can be done with old Fox, in can be done better with VFP. And if you can do it with VB, you can do also it with VFP, without that much modification. As you have already seen.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[DSummZZZ]

Mike,

If it ain't broke, don't fix it!

I think the idiocy isn't in the language or code, more the ridiculously drastic measure of trying to retrofit the system.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[ashthud]

Well this is well out of my interest but i don't think there should be rules on "if it aint broke..." who possibly can say either way.. the whole point of free-will aint it? Anyway maybe im too young and/or inexperienced; i do as i like. Cheers for you help neway!

 

[Olaf Doschke]

Hi Ashtud,

You're not complaining about foxpro, you're complaining about an old version of it. That's okay.

You can be proud to do things with FP 2.x it was not supposed to do. Well, in fact you only programmed some stuff you'd be able to do in VFP anyway. '*' as Password char? It's in VFP as long as I remember.

You're (and your boss) are really wasting your time and money, it's dumb. Updating to VFP is much cheaper than to program certain features in C, viewing it from the aspect of what more features VFP offers. As if you could program everything VFP now offers for about 600 bucks...

It's more than just a recompile needed, but in fact it could work for a start, as VFP is very backward compatible. New features and functions were incorparated without killing older ones. The disadvantage is, you need to redesign to take advantage of new ways, but you can do that by starting from where you are.

Well, your boss seems so narrow that you'll need to do such low level stuff yourself, but maybe you're also stuck in your C world.

Maybe there is even SYS(2600) in FP 2.6, which besides some Memory API calls is a way to adress the RAM directly. But getting at the memory adress of a variable is something you only need in C, not in VFP. Think of the errors you surely made with pointers pointing to wrong adresses. In VFP you're quite safe to not do these errors. Even for API calls you know you can simply stick together everything in a string. BINTOC() is a function capable to do most of the needed transformations of int, float etc., it was much improved in VFP9 with the capability to convert with any needed byte order etc.

And if you intend on working on VFP variables from C code you do that by writing an FLL with the Library Construction Kit. Bit it may have been introduced in FP3 only. You can also do that with VS 2008 C++, and you can work on variables and tables from C that way.

But you need few API calls within VFP anyway. Creating a GUID, that's one thing. Shellexecute (well, there is RUN /N, but Shellexecute often is more capable).

You might like this FLL to help you as a bridge to the C world:

http://www.vfp2c.com/index.html

Don't know if this will work from FP2.x though.

Bye, Olaf.

 

[ashthud]

I said:

...on my way to creating a treeview control with the comctrl32.dll

I've finally finish!! I had to create an extra dll to help me tho =D If anyone is interested i will post my code and the dll.

Ashthud

 

[Olaf Doschke]

ashtud, I don't know, maybe you'll find someone interested, but using ActiveX control with foxpro is quite an old hat. I can only repeat you're just conquering ground that has already been captured long long ago.

With simple math like this: 1 hour of my programming my company will earn 50-100 EUR. So i I'd only need one day to solve a problem already solved with a new foxpro version my boss must be mad if he wouldn't bye me this newer version.

Bye, Olaf.

 

[Olaf Doschke]

buy...

 

[ashthud]

You can use activex with foxpro 2.6? =O

Ashthud

 

[ashthud]

Also, i really *do* understand that a newer version will be the best solution, but it's just not practical for my business.

Plus, i am an apprectice; the more i learn about the inner workings of windows and it's api, the greater the benefit is for me... about 2 hours a day at work and a few hours @ home isnt really that much, plus i can spread my knowledge to other foxpro 2.6 users in my company (who until now haven't bothered using anything but standard controls).
Ashthud


Ashthud

 

[Olaf Doschke]

Well knowing the Windows API isn't bad, but you need rather few calls from VFP6,7,8,9. And with .NET you don't use the Win API any more, you use the .NET framework. Win API will soon be dead knowledge. If I were an apprentice I'd search another job.

Bye, Olaf.

 

[ezopaci]

Why do you need to get the address of variable ? Is this var. string or something else ?
I have some assembler and C code for fox and it can read/write RAM, but get the address of variable is pretty impossible due to complex of memory handling in the foxpro.
There is api for MEMORY handling, but (in dos) foxpro needs some type of "marshalling" of piece of RAM to the addressable space (switch from 32 bit protected mode to the 16 bit real mode, remember it ). There is also limit to 64KB for one "transfer" from fox to the C library, even though dos foxpro can handle much bigger variables.
You can "load" any variable from fox to the addressable space, but it will be only COPY of the data from variable. Not original data in the variable.


Tomas

 

[dbMark]

Which versions of FoxPro are you using, DOS or Windows? FoxPro 2.6 for DOS is strictly DOS, no Windows capability. FoxPro 2.6 for Windows did have some Windows capabilty, notably for screen display and selecting printers, but it is largely viewed as a hybrid at best, with one foot in the DOS world and the other foot in the early Windows world.

Basically, any DOS language is considered "legacy". The last FoxPro release was in the early 1990s as I recall. The last Windows systems which supported native DOS mode were Windows 98 and ME. Windows 2000, XP and Vista all have compatibilty modes.

Perhaps your company's clients don't need programs to run in Windows. But it's probable your company's products will be a harder sell as more time passes.

 

[ashthud]

The company i work for does not sell programmes, or create software for others. We are a manufacturing company that build switchgear... we create programmes for us; to handle attendance, training, stock control and finance stuff.

Like i said, no reason to upgrade, if *anything* happens, itll probably be moving to another language completely like c# or something daft like that.

I am programming in foxpro(2.6) for windows.

I want to be able to return a string from a dll ive built, but i just can't do it. The foxpro app just crashes, i tried LPSTR, LPCSTR and CHAR* as return types in my dll but Foxpro just cant return a character.
My attempt at a solution was: send a pointer (to a string) to my dll, and then get the dll to change its contents.

The solution i thought id found, didnt work =( so my question is still open... how do a return a string to my foxpro app?

Ashthud