In the software development process, there are some seemingly simple problems, but they are easily ignored by ordinary developers. The existence of these "Bugs" affects the commercialization of our software. Listed below are several such problems that the author encountered when using Visual Basic to develop software. The solutions are given here for everyone to discuss and exchange.
1. Prevent the application from loading twice
When our application is running under Windows, during the operation, we sometimes minimize and hide it, or switch to the program manager for other operations, and then want to enter the original application. If we forget If you restart the application you just started, two copies of the same application will be loaded into the memory at the same time. This not only takes up memory space, but also easily causes misoperation and data loss. In order to prevent this from happening, the program needs to be able to give a prompt "already loaded" or directly enter the application that is loaded for the first time. This problem seems difficult to solve. In fact, as long as we understand the mechanism of Windows management applications, it can be easily solved.
We know that for each running application, Windows assigns a unique "Handle" and a module code (Module). When two copies of the same program are run at the same time, the module codes of the two programs are the same. Therefore, as long as we find two identical module codes in the memory, we know that two copies of the program are running and can control it. The two interface functions GetModuleHandle and GetModuleUsage provided by Windows can complete this task. The specific method is as follows. First, declare the API function in a new module file (*.Bas).
DeclareFunctionGetModuleHandleLibKernel(ByVallpPRogName$)
DeclareFunctionGetModuleUsageLibKernel(ByValhModule)
At the same time, create a subprocess named main. The code in the subprocess is as follows:
SubMain()
OnErrorGoToerrMain' error handling
DimhModule' module handle
DimAppCount'The number of applications
appPath$=app.Path /'application startup path
hModule=GetModuleHandle(appPath$ app.EXEName .exe)'Get the handle of the program.
AppCount=GetModuleUsage(hModule)'Gets the module code, that is, the number of running applications.
lfAppCount>1Then'The number of the same application is greater than 1
MsgBox program has been loaded, 64
End' ends the currently started application
Elsc
mainForm.Show'mainForm is the main form of the program
Endlf
ExitSub
errMain:
lfErr<>0Then
MsgBox An error occurred while starting the program, 64
ExitSub
Endlf
EndSub
After the process is completed, under the VB3.0 main menu [options], select the [Project] menu item and set the [StartupFrom] item to Submain, that is, when the program runs, it starts from the Submain subroutine first. This ensures that the above code will be executed. Submain is the subprocess name agreed in VB3.0 and cannot be replaced by other names.
Regenerate the EXE file, start the application under the program manager, then minimize the generated form, and then run it from the program manager. The user will see a message box telling the user that the application has been After loading, the second program terminates execution. The above program is only used to prevent the second program from loading, but it does not automatically enter the first program when the second program cannot be started. To achieve this, the procedures involved are relatively complex and will not be introduced in detail here.
2. Determine the installation path of Windows
In the software we develop, we sometimes directly call small applications provided by Windows, such as calculators, planners, etc.; or we need to put some special files in the Windows or SYSTEM path. Usually, Windows is installed in the C:WINDOWS directory, but users can modify the home directory name of Windows at will. Therefore, in our software, we need to determine the installation path of Windows. For this problem, Windows provides two API functions: GetWindowsDirectory and GetSystemDirectory, which can return the names of the Windows directory and SYSTEM directory.
To this end, prepare a general function GetWinDir, which returns the name of the Windows installation directory. Similarly, you can write GetSysDir, omitted.
Declare API functions in *.BAS module files
DeclareFunctionGetWindowsDirectoryLibKernel(ByValipBufferAsString,ByValnSizeAsInteger)asIntegerFunctionGetWinDir()AsStringDimWindir$Windir$=Space$(144)'144 is the theoretical maximum length of the WINDOWS directory name.
lfGetWindowsDirectory(Windir$,144)=0Then
MsgBox cannot determine the installation path of WINDOWS, 16
GetWinDir=
Else
Windir$=ALLTrim$(Windir$)
ifRight$(Windir$,1)<>“/”thenWindir$=Windir$ “/”
'Add backslash
GetWinDir=Windir$
Endlf
EndFunction
ALLTRIM is a function used to remove null characters in a string.
FunctionALLTrim(FatStr$)AsString
'thisFunctiondeleteSpacecharinstringofFatStr$
DimSlimStr$,I
SlimStr$=FatStr$
I=lnStr(SlimStr$,Chr$(0))'The position of the space
IfIThenSlimStr$=Left$(SlimStr$,I-1)
SlimStr$=Ltrim$(Rtrim$)(SlimStr$))
AIITrim$=SlimStr$
EndFunction
3. Prompt to save data before closing the form
Generally speaking, there are usually 5 ways to close an application:
1. The user selects the [Close] command in the ControlBox of the current form.
2. Stimulate the end command code in the program (such as End, Unload)
3. Exit Windows
4. Close the application in the Windows task list.
5. During multi-document operation, closing the main MDI form will cause the sub-MDI form to close.
Before closing an application, we need to give the user a chance to prompt "Do you want to save data?" or cancel the "close" operation. In VB, the closing of the form triggers the Form_Unload event. We can program this event to control the "close" operation. Assuming that there is already a procedure FileSave used to save files, you can write the program like this.
SubForm_Unload(CancelAslnteger)
selectcastMsagbox("Save data?", 3 32)
'Yes, No, Cnacel three options
case6'YES
FileSave' save data
case2'cancel
Cancel=TRUE'Cancel the close operation
caseelse'NO' does not save, perform shutdown operation
Endselect
EndSub
The Cancel variable in the above code is an inherent outgoing variable of the Form_unload event itself. It delivers messages to the Windows control process to control the direction of the program.
The above three examples are just some minor problems in the process of software improvement. To make the software stable and reliable, a lot of careful and careful work needs to be done. Some problems can be solved by exploring the potential of VB itself and deeply mastering the operation skills of some processes; while some more complex problems involve the underlying operations of Windows and can be easily realized using Windows API functions. Of course, this requires a certain understanding of the functions and mechanisms of Windows. As the level of Windows programming improves, we will gradually learn and like to use API functions to assist in completing program coding. ->