Tuesday, September 30, 2014

FoxPro form flashes on the screen and disappeares

I am working on my first Visual Foxpro program. My program was not waiting for any event and just closed immediately. I could not figure out the reason until I found this article.

http://www.alvechurchdata.co.uk/company/foxflash.html

FoxPro form flashes on the screen and vanishes

Everybody meets this problem with their first Visual FoxPro executable; the program runs well in the development environment but fails when run as a stand-alone executable from Windows. The FoxPro window just flashes on the screen and then vanishes. You can search VFP Help for terms like "flash", "vanish" and "disappear" but you will find nothing. The information is hidden away under "How to: Control the Event Loop" and you won't be able to ship your exe until you find it.
This problem crops up because Visual FoxPro is now an event-driven language. It runs through the code for your form, reaches the end, and the program terminates when there is nothing more for it to do. Everything vanishes from the screen. The same thing will happen if your application is based on a main menu; FoxPro will run through the code to create the menu, the menu will flash on the screen but then the program terminates and the menu vanishes.
The solution is a simple one once you realise what FoxPro is doing. You have to tell VFP to start its event-processing loops. The command that does this is:
Read Events
You'll need to add this code in different places depending on whether you are using a form, a menu or a program as the main element of your application.
If you are using a form then add this as the last line in the Activate event. This will allow the form to load and initialise itself before going into the event processing loop and waiting for mouse and keyboard events.
In a menu, add it to the CleanUp code snippet. Select General Options from the View menu then click the Cleanup... tick box. An edit window will open behind the dialog; click OK to close the dialog window and the CleanUp edit window will remain:
[VFP Edit window for menu cleanup code]
If you have a program as the main element of your project then add the Read Events line immediately after you have set up the user interface by loading a form or menu. Fox will then stop executing this sequential code and will start monitoring keyboard and mouse events, waiting to see what it should do next.

One last thing to remember

[Cannot Quit Visual FoxPro message] This will start the event processing loop but we need to stop the loop in order to close the application. If you forget to do this then you'll hit the second most-common problem - the "Cannot quit Visual FoxPro." message.
You avoid this by using the Clear Events command to stop the event-processing loop. Execution will then continue from the line following the Read Events command in the main program.
Read more details on being unable to quit FoxPro here.

Friday, April 25, 2014

Windows Script Host


Microsoft Windows Script Host (WSH) is a language-independent scripting host for Windows Script compatible scripting engines. It brings simple, powerful, and flexible scripting to the Windows 32-bit platform, allowing you to run scripts from both the Windows desktop and the command prompt.

Using Windows Scripting Host, VBScript performed tasks that the Windows shell (batch scripts) simply could not handle. Windows Script Host is ideal for non-interactive scripting needs, such as logon scripting, administrative scripting, and machine automation.

This is the link for Windows Script Host
http://msdn.microsoft.com/en-us/library/9bbdkx3k(v=vs.84).aspx


In VBScript, we can create Windows Script Host (WSH) Objects and automate manual tasks.

These are the 14 WSH Objects:

Scripting.Signer Object  
Enables an author to sign a script with a digital signature and a recipient to verify the signature's authenticity and trustworthiness.

WScript Object 
Provides access to most of the objects, methods, and properties in the WSH object model.

WshArguments Object
 Gives you access to the entire collection of command-line parameters — in the order in which they were originally entered.

WshController Object
 Exposes the method CreateScript() that creates a remote script process.

WshEnvironment Object
 Gives you access to the collection of Microsoft Windows system environment variables.

WshNamed Object
 Provides access to the named command-line script arguments within the WshArguments object.

WshNetwork Object
 Gives you access to the shared resources on the network to which your computer is connected.

WshRemote Object
 Provides access to the remote script process.

WshRemoteError Object
 Exposes the error information available when a remote script (a WshRemote object) terminates as a result of a script error.

WshScriptExec Object
 Provides status and error information about a script run with Exec, along with access to the stdIn, stdOut, and stdErr channels.

WshShell Object
 Gives you access to the native Windows shell functionality.

WshShortcut Object
 Allows you to create a shortcut programmatically.

WshSpecialFolders Object
 Allows you to access the Windows Special Folders.

WshUnnamed Object
 Provides access to the unnamed command-line script arguments within the WshArguments object.

WshUrlShortcut Object
 Allows you to create a shortcut to an Internet resource, programmatically.
 
Link: http://msdn.microsoft.com/en-us/library/a74hyyw0(v=vs.84).aspx


This is the reference page:
http://msdn.microsoft.com/en-us/library/98591fh7(v=vs.84).aspx


Wednesday, April 2, 2014

Script to load program in administrator elevated mode

One of our users needs to run a program in elevated mode. I added her in the local admin group, but she still have to right click the shortcut and select "Run as Administrator" and then click OK in the pop up UAC window. The user complained about all the clicks.

I googled it and found this script to avoid all these steps. User just double click the shortcut to the batch file and the batch file runs the program in elevated mode.


https://sites.google.com/site/eneerge/scripts/batchgotadmin

Basically this just creates a VBS Script on the fly and invokes the batch script using it. It checks to see if the current window is running as administrator by attempting to create a folder that requires administrative access. If the directory can not be created, then it invokes the UAC dialog, then closes the non-admin window. The script can also be executed from an already open administrative CLI.
 
 
========== Batch file: RunProgram.bat =================================

@echo off

:------------------------:
: BatchGotAdmin     :
:------------------------:

REM  --> Check for permissions
>nul 2>&1 "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system"
REM --> If error flag set, we do not have admin.
if '%errorlevel%' NEQ '0' (
    echo Requesting administrative privileges...
    goto UACPrompt
) else ( goto gotAdmin )


:UACPrompt

    echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
    echo UAC.ShellExecute "%~s0", "", "", "runas", 1  >> "%temp%\getadmin.vbs"
    "%temp%\getadmin.vbs"
    exit /B

:gotAdmin

    if exist "%temp%\getadmin.vbs" ( del "%temp%\getadmin.vbs" )
    pushd "%CD%"
    CD /D "%~dp0"

:--------------------------------------
REM  creat a temp batch file to run the real program
    
echo net use p: /delete /y >%temp%\runProgram-temp.bat
echo net use p: "\\Server1\program files" >>%temp%\runProgram-temp.bat
echo net use n: /delete /y >>%temp%\runProgram-temp.bat
echo net use n: \\Server1\groups >>%temp%\runProgram-temp.bat
echo p:\myProgram\myProgram.exe >>%temp%\runProgram-temp.bat
echo exit >>%temp%\runProgram-temp.bat
start /min %temp%\runProgram-temp.bat

======================= End of Batch file =======================