Easy Code: tutorials for Masm compiler

Started by Ramon Sala, December 24, 2004, 07:38:37 PM

Previous topic - Next topic

Ramon Sala

In this section there will be Easy Code small and dedicated tutorials, specially oriented to visual projects, for you to learn easily how to program applications with this IDE.

Enjoy Easy Code!

Ramon
Greetings from Catalonia

Ramon Sala

#1

Adding child controls

The attached help file shows how to add child controls to a window and how to receive control messages in its own window procedure. Anyway, in most cases the window procedure for a child control is not needed and it's enough processing the messages received by its owner window through the WM_COMMAND and/or WM_NOTIFY messages.

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala

#2

Getting child controls handle

The attached help file shows how to get the handle for a child control using its control ID. The handle for a control is needed in many operations with child controls.

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala

#3

Controlling application message loop

The attached help file shows how to get full control over the application message loop. In most cases it is quite enough to process messages in their corresponding procedures. Anyway, you can have more control over application messages if you need.

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala

#4

MDI applications

The attached file shows how MDI windows work. The Easy Code application includes an MDI application as an example (Examples folder in Easy Code installation directories).

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala


Creating windows at run time

The Create.zip attached help file shows how to create a window at run time. In the SDIApp.zip attached Easy Code example project, you can see how to do it.

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala


Object procedures

The ObjProcs.zip attached help file shows how to use object procedures properly and how to write code in them.

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala

#7
Modal windows

The ModalWin.zip attached help file shows how to use Window and/or DialogBox objects to create modal windows in visual projects.

Enjoy it!


REMARKS: You should never hide a modal window.


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala

#8

TabStrip common control

Once unzipped the attached TabStrip.zip file, you will have a folder named TabStrip with a whole project and a help file inside. You can see how easy it is to program an application using a Tab control. Have a look at the project and read the help file.


REMARKS: The TabStrip project needs Easy Code version 1.00.0012 or later.

Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala


Put an icon in the task bar

Once unzipped the attached Memory.zip file, you will have a folder named Memory with a whole project that tells you the total and available System memory. You can see how easy is to program an application having an icon in the taskbar.


Enjoy it!


[attachment deleted by admin]
Greetings from Catalonia

Ramon Sala

#10
Raw data and files

The Easy Code resource editor has been made to allow the user to create all kind of resources and, at the same time, make it as easy as possible, but being limited for the syntax of the resource compiler (RC.EXE). As a result, you can add accelerators, menus, images (icon, cursor or bitmap), strings, a version resource and Raw Data.

A raw data resource permits the inclusion of binary data directly in the executable file and it specifies one or more integers or strings of characters. Integers can be specified in decimal, octal or hexadecimal format. RC compiler does not automatically append a terminating null character to a string. The string is a sequence of the specified ANSI (byte) characters unless explicitly qualified as a wide-character string with the L prefix (Unicode).

The block of data begins on a DWord boundary and RC performs no padding or alignment of data within the raw-data block. It is the programmer's responsibility to ensure the proper alignment of data within the block.

The following are some examples of raw data:

10,20,30,40                      Four integer (16-bit) values.
"A","B","C","D"                 Four byte (8-bit) values.
"Readme.txt\0"               Double-quoted text to specify it is a string (null-terminated).

L"Readme.txt\0"             Unicode null-terminated string (L means Unicode, otherwise it is ANSI)
"\r"                                  A control character (8-bit) correspondig to ASCII 13 (<Carriage Return>).
0x40                                 A Hex integer (16-bit) value corresponding to 64 decimal.


This raw data has to be typed exactly the same in the Easy Code Raw Data resources window so that RC does not generate any error at compile time. In fact, raw data resources are usually used for binary data or, eventually, for ANSI strings, as strings defined in a String table are always Unicode.

In some cases, it would be interesting to add a whole file as a resource. As the RC compiler has no way to do that, Easy Code has a user-defined resource to accomplish this task. User-defined resources must have a value greater than 255, so Easy Code has the RT_FILEDATA reserved word (value 256). In the resource editor, adding a file is done in the Raw Data resources window. So, how does Easy Code know if it is raw data or a file name? It just looks in the Res folder for a file having the typed name. If it exists, an RT_FILEDATA resource will be created. To find it at run time, you will have to specify RT_FILEDATA in the 'ResourceType' parameter of the FindResource function. On the other hand, if there is no file in Res folder having the typed name, a normal RCDATA resource will be created and it will be found as RCDATA type.

Note that a file name could be treated as normal raw data if the file it specifies is not found in Res folder, but if it was entered without double quotes, the RC compiler will generate an error. On the other hand, if the file name is double-quoted, it will be treated as a Raw data string (RCDATA type).

Ramon
Greetings from Catalonia

Ramon Sala

#11

Checking previous instances

In some applications is not possible to have more than one instance running at a time (i.e the ECPlayer or MIDIPlay examples included in Easy Code\Examples). When that is the case, or for any reason you want just one instance to be running, you must check it during the main window creation. In Classic projects you have to write all the code to find out whether there is already another instance running and, if there is one, returning -1 in order not to continue the creation of the window. In Visual projects that is really simple with the App object. This interesting object may be referenced in any part of the code and has several properties (see the Easy Code help). One of them, Previous, always returns the handle to the window of a previous instance (if any). You just have to check the App.Previous and if it is NULL no other instance is running, so you can go ahead. Otherwise, the returned value will be the handle to the main window of the already running instance. The best place for checking previous instances is in the WM_CREATE message. For example:

   .If uMsg == WM_CREATE
      .If App.Previous != NULL
         Return (-1)   
      .EndIf
      
   .ElseIf uMsg == WM_CLOSE
      Invoke IsModal, hWnd
      .If Eax
         Invoke EndModal, hWnd, IDCANCEL
         Return TRUE
      .EndIf
   .Endif



On the other hand, if you want to show the instance which is running and bring it to top, write the following code:


   .If uMsg == WM_CREATE
      .If App.Previous != NULL
         Invoke ShowWindow, App.Previous, SW_SHOWNORMAL
         Invoke SetForegroundWindow, App.Previous
         Return (-1)   
      .EndIf
      
   .ElseIf uMsg == WM_CLOSE
      Invoke IsModal, hWnd
      .If Eax
         Invoke EndModal, hWnd, IDCANCEL
         Return TRUE
      .EndIf
   .Endif



If another instance is running (App.Previous != NULL) and you do not want it to run, then you should return -1. No other way of exitting the applicaction is recommended as Easy Code creates brushes, fonts and other resources for Windows and Controls in Visual projects. Returning -1 will destroy the window before being shown and will release all associated resources. You can have a look at the MIDIPlay example (available from Easy Code version 1.00.0017 or later) which uses the App object to avoid more than one instance to be running at a time.

Enjoy it!
Greetings from Catalonia

Ramon Sala

#12
The App object


The App object is only available in visual projects and it stores useful information about the running application. Using this object avoids having to declare global variables to access the required information anywhere in the project. It has the following members:


Accel - HACCEL type containing the handle to the accelerator table, if any, or NULL.

CommandLine - LPSTR type pointing to the effective addres of the command line (excluding the program name and path).

FileName - LPSTR type pointing to the effective addres of the executable file name.

Header - LPSTR type pointing to the effective addres of the header (the text in Header field of the Project properties).

Instance - HINSTANCE type containing the handle to the instance.

Main - HWND type containig the handle to the main window (start up window).

Major - LONG type containig the major version.

Minor - LONG type containig the minor version.

Path - LPSTR type pointing to the effective addres of the path for the application.

Previous - HWND type containing the handle to the main window of a previous instance, if any, or NULL (see previous topic).

ProcessID - DWord type containing the IDentifier of the process.

Revision - LONG type containing the revision of the version.

ThreadID - DWord type containing the IDentifier of the thread that created the main window (App.Main).


The App object is used like a structure and may be invoked anywhere in the project. Here are some examples:

Invoke GetWindowText, App.Main, lpszBuf, MAX_PATH
Invoke LoadString, App.Instance, IDS_STRING, lpszBuf, MAX_PATH
Invoke SetWindowText, App.Main, App.FileName
Invoke SetCurrentDirectory, App.Path


So, using the App object saves time and makes accessing application's data easier.

Ramon
Greetings from Catalonia

Ramon Sala

#13
Static and dynamic linking

Visual projects need to link the Easy Code visual library as it manages the appearance and behavior of all existing objects (windows and controls). You can link it statically (default option) and the size of the final executable file will be larger but it will have no dependency, or you can link it dynamically and the size of your application will be smaller, but then you will have to join the ECDllMsr.dll, or ECDllGo.dll for GoAsm version (located in the Lib\Dynamic subdirectory of the Easy Code application path), when distributing your application. The only advantage of dynamic linking (apart from the smaller size of the executable file) is that you just need one copy of the ECDllMsr.dll in the System directory (usually \WINNT\SYSTEM32 for Windows NT/XP/2K and \WINDOWS\SYSTEM for Windows 95/98), even though you have a lot of Easy Code made applications. Also, the ECDllMsr.dll might be in the application's directory, but then you should have to place a copy in each Easy Code application's folder (if the project was built in Debug mode, then the ECDllMsd.dll (or ECDllGo.dll for GoAsm version) will be needed instead). So, take into account the following:

- Statically linked applications do not need any other Easy Code file, as the executable file already includes the visual library.

- If your application was dynamically linked, you should join the ECDllMsr.dll (or ECDllGo.dll for GoAsm version) file with the executable. If you distribute your application with an installer program, it should place the ECDllMsr.dll (or ECDllGo.dll for GoAsm version) file in the System directory.

- If the executable was dynamically linked, but built in Debug mode, then the ECDllMsd.dll (or ECDllGo.dll for GoAsm version) file has to be joined instead. Take that into account, although it is not very usual distributing applications in Debug mode.

- The best place for the run-time ECDllMsr.dll or ECDllMsd.dll files is the System directory. In that way, only a copy of them is needed even though there are many Easy Code applications installed. If not, you should place a copy of ECDllMsr.dll (or ECDllMsd.dll) in each Easy Code application's folder.

- If you always distribute your dynamically linked applications in Release mode (which is the usual way), you just need to join the ECDllMsr.dll file (ECDllMsd.dll is not needed at all). On the other hand, if the application was built in Debug mode, then the ECDllMsd.dll file will be needed instead, but Debug building is just for developing the application in order to find and fix bugs. Once it works fine, the program is built in Release mode for being distributed.


Llinking the Easy Code visual library statically gives the advantage of having an executable file which has no dependency, so no other Easy Code file has to be distributed with it, even though the .exe file is a little larger. That is not usually a problem as assembly made applications are much smaller than any other programming language, but anyway you decide.

REMARKS: The GoAsm version of EasyCode does not have the debug version of the dynamic link libraries. Instead, it has the unicode version (ECDllGou.dll) which has to be distributed with the application ONLY if it was built in unicode mode. If not, the ECDllGo.dll file should be distributed.

Enjoy it!

Ramon
Greetings from Catalonia

Ramon Sala

#14
Menus


There are two ways of building a menu in Easy Code depending on the type of project, visual or classic. The first way is creating a menu resource in the Resource Editor and then setting it to a window using the SetMenu API function, usually in the WM_CREATE message. The second way (just for visual projects) sets the menu automatically to the window for which the Menu Editor was opened and allows you to assign the accelerator keys at hte same time.


First method (the classic way)
==================


Open the Menu Editor dialog box by clicking Project-->Add Resource-->Menu, design the menu you want. See the Easy Code help (The Menu Editor topic) to learn how the menu Editor works. Then, in your code, load the menu resource and set it to a window so that it can be used.




Second method (just for visual projects)
========================


In visual projects you can design and set a menu in the same way (first method) but, besides, you can make a menu to be automatically set to a window. To do so, open the Menu Editor but using the Tools--> Menu Editor menu option (or <Ctrl+M>), while the window which you want the menu to be set to is the active window. Then, you will be able to design a menu and add accelerator keys which will be automatically set to the active window (that mentioned in the Menu Editor's caption). After that, you can test the window (Build-->Test <Window name> or <Shift+F5>) to see how the menu looks like. The Easy Code visual library takes care of the menu and its accelerator keys (if any), so you do not have to do anything else.

Two projects using both methods are attached. Project1.zip uses the first method, where a menu resource is created in the Resource Editor an then it is loaded and set to Window1 in the WM_CREATE message. Project2.zip uses the second method, and it can be seen by testing Window1.



Enjoy it!

Ramon


[attachment deleted by admin]
Greetings from Catalonia