How to See Who’s Connected to Your Wi-Fi Network with VFP9 ? 1

[mydocpro]

Typing "Net View" in Command Prompt...

... (leads to):

But, might there be a way to 'capture' this in 'myVFP9.app'?
... To obtain the list of computers connected to your WIFI Network ("\\INSPIRON","\\XPS15", etc.)
... unto a table-cursor or something?

The ultimate goals are:
(1) Synchronize data with 'known' computers (if feasibly connected) ... and
(2) Be aware of 'unknown' computers connected to your computer-network

Utmost thanks and blessings in advance for any of your thoughts great or small,
-Philip

 

[Olaf Doschke]

net view is a list of servers in your workgroup/domain, not a list of wifi connected devices.
Anyway, any shell command output can be directed to a file with >
net view c:\temp\netview.txt

You should rather look for API functions giving you the data you want to see.

Bye, Olaf.

 

[Olaf Doschke]

About connected wifi clients: Unless you set up your computer itself as wifi access point, wifi connected devices show up in your routers administration web interface, as it's the typical wifi access point.

Bye, Olaf.

 

[JRB-Bldr]

Olaf is correct in that Users on your WiFi Network may or may not be the same as Users on your Workgroup/Domain.

Someone 'hijacking' a ride on your WiFi Network to gain access to the web may NOT be using your Workgroup/Domain at all.
For that you typically need to look at the identified MAC addresses and/or SSID's within the WiFi Router.

I'd recommend that you first need to clarify your needs and that would make your resolution significantly more effective.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Net view is even more blatantly wrong than adressing domain users instead of wifi connected devices, as it lists LAN resources, not wifi connected devices, it lists servers, shares.

http://www.howtogeek.com/204057/how-to-see-who’s-connected-to-your-wi-fi-network/

Bye, Olaf.

 

[mydocpro]

Exceeding thanks Olaf and JRB! Yes, it is "Users on your Workgroup/Domain" ... to synchronize Data tables, via VFP if feasible.
Below is 'awkward' coding (too many if-then conditions) to 'discover' appropriate "cNetworkDataDirectory"s to sync with the HomeCompDirectory:

cNetworkDataDirectory=""
fso =createobject('Scripting.FileSystemObject')
DO CASE
CASE HomeCompDirectory = "\\XPS15\c\dpw\data"	&& might look for \\INSPIRON 1st, else \\TOSHIBA
	cNetworkDataDirectory="\\INSPIRON\c\dpw\data"
	lEvalThe2DataDirs=fso.FolderExists(cNetworkDataDirectory)
	IF lEvalThe2DataDirs	&& Go to next directory
		= Checkfiles(cNetworkDataDirectory)
	ELSE 
		cNetworkDataDirectory="\\TOSHIBA\c\dpw\data"
		lEvalThe2DataDirs=fso.FolderExists(cNetworkDataDirectory)
		IF lEvalThe2DataDirs
			= Checkfiles(cNetworkDataDirectory)
		ELSE 
			cNetworkDataDirectory=""
			RETURN && Can't access it so don't waste time with it
		ENDIF 
	ENDIF 
CASE HomeCompDirectory = "\\INSPIRON\c\dpw\data"	&& might look for XPS15 1st, else TOSHIBA
	cNetworkDataDirectory="\\XPS15\c\dpw\data"
	lEvalThe2DataDirs=fso.FolderExists(cNetworkDataDirectory)
	IF lEvalThe2DataDirs
		= Checkfiles(cNetworkDataDirectory)
	ELSE 
		cNetworkDataDirectory=""
		RETURN 
	ENDIF 
CASE HomeCompDirectory = "\\TOSHIBA\c\dpw\data"	&& might look for XPS15
	cNetworkDataDirectory="\\XPS15\c\dpw\data"
	lEvalThe2DataDirs=fso.FolderExists(cNetworkDataDirectory)
	IF lEvalThe2DataDirs
		= Checkfiles(cNetworkDataDirectory)
	ELSE 
		cNetworkDataDirectory=""
		RETURN 
	ENDIF 
ENDCASE
*(Checkfiles() function checks HomeCompDirectory files against cNetworkDataDirectory files ... using ADIR() comparisons.

So I pondered ... the Net view command?, something like with Olaf's first suggestion ("net view c:\temp\netview.txt") ... based on your advice(s).
A promising API example (

http://www.news2news.com/vfp/?example=167&function=255&PHPSESSID=c45afd9e1447f9741efc7db2b5737253)

yielded some network 'properties' ... albeit not the '\\ComputerUser'(s).

In sum, I'd hoped ... to sift out '\\ComputerUser\dpw\data'(s) ... to compare data with ADIR()s.

Utmost thanks and blessings!
Philip

 

[Olaf Doschke]

You forgot > in net view >c:\temp\netview.txt
Now I don't get what you really want to determine, devices attached to Wifi (router web interface) are a whole different thing than users on a network (active directory perhaps?) and your code shown, which at a glimpse on it determines locations of files or file shares, but not at all users.

So what is your real world goal to find out?

Bye, Olaf.

 

[mydocpro]

ShellExecute(0,'open','cmd', '/C net view > c:\temp\netview.txt','',[b]0[/b])

(Emulating Olaf (above) and Zia Mughal

https://pclandpk.blogspot.com/2014/...owComment=1475388655112#c1261684761801184455)

... this may also require a sleep() pause after the code. Anyway, this API works for net view; fwiw. (#0 keeps the 'black DOS box' invisible)

Albeit, I'll experiment while observing your somber suggestions, and report back with results after some rest.

Utmost blessings and thanks!
Philip

 

[JRB-Bldr]

to synchronize Data tables, via VFP if feasible

???

Aren't all of your application data tables centralized into a single location?
That would be a 'normal' configuration.
And it would not require any 'synchronization' since everyone would be using the same data tables.

If this is not the case, then perhaps there might be a need to review the application data architecture to see if there might be a better way of doing things so as to eliminate the need for 'synchronization'

Good Luck,
JRB-Bldr

 

[mydocpro]

Solved my friends! Thank you for helping me work it through professionally,

... And for your excellent thoughts, JRB. My problem is 90% solved (praise God) (per my last post). Albeit, if further results become significant, I'll try to post the specifics for all to benefit. (Basic VFP coding is all that remains.)

Partially on topic: Regarding centralization ... my take (fwiw with 27 years of Foxpro and EMRs):

Unfortunately, strict centralization is oft detrimental with regards to (my) EMR/EHR databases: since physicians must travel with their servers (laptops) ... and do fail with cloud servers (another topic).
... to securely download extensive private health information for CMS and BCBS (vicarious photos, progress notes, charts, history & physicals, etc.) on-the-fly ... at remote hospitals, clinics, nursing facilities, etc.

Utmost thanks and blessings my excellent friends!
Philip

 

[Olaf Doschke]

You can simply detect whether a configured network share exist, if someone starts your app, so you would let your software detect whether it runs standalone/offline or in the LAN/online and let it decide what to do/sync/upload/download. Why would you need net view, a simple DIRECTORY("\\network share") would work or DRIVETYPE("E"), if you map a share on drive E.

Bye, Olaf.

 

[mydocpro]

Thank you Olaf: DIRECTORY("\\ServerUser1"); that command also took about 2 seconds when DIRECTORY("\\ServerUser1") = .F. (nonexistent on network)

I will probably prefer your original encouragement that led to:

ShellExecute(0,'open','cmd', '/C net view > c:\temp\netview.txt','',0)

... which takes the same 2 seconds (or less) for the text file to form and to derive all the existent "\\ServerUser"s from that text file.

Utmost blessings!
Philip

 

[JRB-Bldr]

since physicians must travel with their servers (laptops) ... and do fail with cloud servers

OK, I get why you are not having your remote ('satellite') users utilize a single data source.
But, in reality you are using a single data source - the only difference is that you are having to periodically sync the central data with the individual stand-alone 'satellite' user's data.

Your original question leads me to think that you are having your central application control and initiate the synchronization by examining who is currently connected.

Maybe that is an incorrect assumption on my part.
However if that is correct, they why are you doing it that way?
Why aren't the stand-alone 'satellite' user's applications 'knowing' when they are connected and THEY (the remote applications) initiate the synchronization?

Sure, it would not support an 'awareness' of non-authorized users on your Workspace/Domain, but that too could be controlled centrally in a variety of ways - none of which would require use of NET VIEW.
Plus, by the time your central application became "aware" of a non-authorized user via NET VIEW it would likely already be too late - they would already be attached to and in your Workspace/Domain.

Perhaps you have other reasons for why your application and it's 'satellite' components are configured as they are, but it does not seem to be an optimal application architecture/configuration.

Good Luck,
JRB-Bldr

 

[atlopes]

The ANETRESOURCES() function can retrieve neighbor computers.

CLEAR

LOCAL Domain AS String

* set as the target domain, or leave blank to look into the local computer's domain/workgroup
m.Domain = ""

* if not set, retrieve the domain/workgroup of the local machine
IF EMPTY(m.Domain)
	LOCAL WMI
	LOCAL Computer

	m.WMI = GETOBJECT("winmgmts:\\.\root\cimv2")

	m.Computer = m.WMI.InstancesOf("Win32_ComputerSystem").ItemIndex(0)
	
	m.Domain = m.Computer.Domain
ENDIF

LOCAL ARRAY NetComputers(1)
LOCAL NetComputer

* retrieve computers in the domain/workgroup
IF ANETRESOURCES(m.NetComputers, m.Domain, 0) = 0
	MESSAGEBOX("No computers found in the neighborhood")
ELSE
	FOR EACH m.NetComputer IN m.NetComputers
		? m.NetComputer
	ENDFOR
ENDIF

 

[Olaf Doschke]

You're not really interested in seeing all network resources, are you? Yes, DIRECTORY has a long timeout, if the directory is not found, especiall with UNC paths, but it would make me wonder if there is no wa to shorten that time, most probably not with a VFP setting, but an OS setting, registry entry, for example. You don't need to do this blockingly. First of all once at the startup won't hurt.

With a net view or alos ANETRESOURCE you don't take more time, but the network is flooded with requests, while you only need to know whether your software can see and access the central share.

Bye, Olaf.

 

[mydocpro]

Atlopes: I tested your astonishing code (which I would have used) ... but after experimenting, I discovered it to be consistently lagging ... 1 to 1.5 seconds ... compared to my 'desperado' routine ... which consistently lags up to 0.5 seconds (via a Dell XPS15 I7 ssd):

DECLARE INTEGER ShellExecute IN shell32.dll INTEGER hndWin,STRING cAction,STRING cFileName,STRING cParams,STRING cDir,INTEGER nShowWin
ShellExecute(0,'open','cmd', '/C net view > c:\dpw\netview.txt','',0) 
cStringOfPotentialUsers=FILETOSTR("c:\dpw\netview.txt")
MESSAGEBOX(cStringOfPotentialUsers)

JRB and Olaf: Things do require polishing, yes. The ShellExcecute()/netview, while 'incorrect', seems required because it is lightning fast compared to ANETRESOURCE, Directory(), etc. for auto-sync purposes.

JRB: Today's physicians (myself included) oft take their laptops to their cars and motels for data downloads (not just Satellites); some physicians are quite blessed with WIFIs in their cars, homes, iphones, motels, and hospitals ... but most are cursed by awkward and slow EMR cloud servers. "Take the server with you" is my bias (so far).

Utmost blessings and thanks always,
Philip

 

[JRB-Bldr]

I am glad you are satisfied with your solution.

Just to clarify, my use of the term 'Satellites' was not to suggest using satellite communications.
I used the term as a substitute for 'remote' as it applies to the applications themselves which are External (or Satellite) applications and are not tightly connected to the central application.
Instead they work somewhat separately and independently.

Good Luck,
JRB-Bldr