CAD techniques on Windows CE - Redlining images
Abstract
The Project allows you to mark changes on the .bmp files in the field and allows the changes to be stored permanently on the hard disk. The user can retrieve and discuss those changes later.
The changes are stored in a separate file, but this file works synchronously with the main file to such an extent that the end user never knows the difference, and does not feel that he is working with two files.
The Project is developed using Visual C++ toolkit for Windows CE. Microsoft Foundation class is used to a good extent for developing the project quickly and efficiently. Taking into consideration that memory is the key factor in a mobile device, the project was developed to perfection and occupies very less memory in the device.
Introduction To Redlining
In the Dr.DWG product, the process of making changes in the CADD file without affecting the actual file itself is called Redlining. The main objective of Dr.DWG is to provide an efficient CADD viewer that offers more functions at a lesser cost.
Since Dr.DWG is essentially a "viewer" and not an "editor", it uses an alternate way to mark changes in a CADD file. This feature is important since the designs are always subjected to changes following client requests or to satisfy various demands.
The " Redlining" feature achieves this efficiently by making the changes to be stored in a separate file, but operating (opening, viewing, closing, zooming) synchronously with the CADD file (Active in the Dr.DWG CADD viewer). The file with the stored changes is saved with the same name as the CADD file, but with _dwg appended on to it. While opening the file, the Dr.DWG viewer searches for any "_dwg" file and if any is found, it is opened simultaneously.
The feature allows different forms of marking like lines, circles, rectangles, "clouds", and freehand "clouds". The user can also enter text that explains the marking.
About the Project
We divided the project into 3 major tasks.
- Allowing Marking on the file with Rubber Band Dragging facility
- Linked List Storage of Strokes, and Serializing Linked List
- Selecting & Editing Previous Strokes
- Storing & Synchronizing "_dwg" file with ".bmp" file
Allowing Marking on the file with Rubber Band Dragging facility
Redlining allows the user to have different types of markings with the "Rubber Band Drag" facility. A basic RedObject is maintained whose value determines the currently selected object for marking. The figure shows the RedObject values and Corresponding Object selected for marking.
The user can select the object of his choice from the menu. During the selection, the red object is initialized to its corresponding value.
The actual drawing starts from the stylus hit (equivalent to WM_LBUTTON DOWN). The current point is marked as the starting point of the new mark. On further dragging, the previous image is erased and the new image is drawn between the starting point and the current point using a CClientDC.
Once the stylus is up (equivalent to WM_LBUTTONUP) the image is stored to Linked List and it is drawn every time when OnPaint is called. The starting point and previous point values are made null.
If it is a text object is selected by the user, in response to a WM_LBUTTONUP call, a dialog box is shown that receives the text from the user.
Linked List Storage of Strokes and Serializing the Linked List
Each stroke in the Redlining is to be stored so that it can be called each time in OnPaint function when WM_PAINT message is generated. Here we use the LinkedList data structure to store the strokes. The structure is as follows:
On every completion of a stroke (when WM_LBUTTONUP is generated after Choosing any RedObject), the stroke is stored in the LinkedList as a new node with the current values like starting point, endpoint, red object, text stored to the corresponding fields in the CShape Object. The next pointer is made to point NULL since it is the last stroke.
The head pointer stores the first stroke and it will always point to that first stroke. This is useful to redraw all the strokes in the OnPaint.
MFC's Document/View Architecture's advantage of splitting the document object from the view object, made the process of permanent storage of the document much simpler using the CArchive class. The usage of a Linked list made this process much simpler. The code below best explains how the object is stored and retrieved from the file.
Selecting & Editing Previous strokes
This module allows the user to edit any previous strokes he has made in the diagram. For editing, the user has to choose the Edit mode from the command bar or press Alt + e. The redobject is made to 5 - indicates editing mode -. On this mode if a WM_LBUTTONMESSAGE is received, the point of click is compared with each object one by one. If any object passes through the point, it is selected and stored as selectednode.
On "Paint", the system checks for any selected node. If it finds anything, it uses the object variable of the selected node to find the type of the object. It then uses the parameters accordingly to draw that object. In addition, it draws Focus Rectangles around that object as a mark of its selection.
When an object is selected, the system begins to respond for Alt+WM_LBUTTONDOWN and displays PopUp Menus. These menus have options for editing the properties of the object, or deleting the object itself. These controls can also be selected from the command bar. The user can cut, copy, or paste an object. A separate clipboard node is maintained for this purpose
After selecting Edit Properties, the system shows a Property Editor that carries all the parameters and allows user to edit them directly. The changed effects are reflected immediately upon closing the dialog. If the user chooses delete or presses Alt+D, then the object is deleted permanently.
Storing & Synchronizing "_dwg" file with ".bmp" file
The usage of a serialized Linked List and of CArchive makes storing and synchronizing very simple.
FileOpen
The OnFileOpen function will generate a FileOpenDialogBox and receive the name of the .bmp file to be opened. It stores the filename in the Document variable (szFname). This file name is used to load the Device Independent Bitmap during every OnPaint call.
Simultaneously, the .bmp extension is truncated from the filename and "_dwg" is concatenated to it. The system searches for any file with this new name in the current directory. If it finds one, it calls OnOpenDocument(newfilepath with "_dwg").
If no _dwg file is found it leaves it as it is. In both the cases, the new path with "_dwg" is set as the path for the Document using the call SetPathName(newfilepath with "_dwg")
File Close
Since the Document Path is being set in the File Open itself, the file closing becomes much simpler with a single call of OnSaveDocument(GetPathName()). To avoid unnecessary savings, the modified flag is used. During every modification, SetModifiedFlag(TRUE) is called and after every time the file is saved and during initialization, SetModifiedFlag(false) is called. The value of Modified Flag is obtained by IsModified() call.
Memory Occupancy Details
The Project Occupies very less of memory in the mobile device. The table shows details
Memory Occupied in HPC (SH3 Release version)
59.0 KB
Memory Occupied in Emulation (WCE ex86em version)
78.0 KB
Runtime memory in Desktop Emulation
3400-3800 KB
Obstacles Faced
The following were the obstacles faced in the project:
- The Normal call of LoadBitmap(filename) is not supported in Windows CE, and we needed to go for loading DEVICE INDEPENDENT BITMAP using the API call SHLoadDIBitmap(pDoc->szFname).
- The Operator Overloaded functions of CString such as +=, + are not supported in the HPC. The CString's Format Command is also not successful. So we used SetAt() functions.
- We had to use Unicode while naming the files and assigning the path to the Document class.
- Special care is required while Invalidating Screen because it takes a long time in HPC. InvalidateRect with (False) argument was used wherever possible.
- A major problem was encountered with selecting ellipses. Unlike Windows 9x, Windows CE does not support CRgn::CreateElipticalRegion, or CDC::BeginPath or using floodfill. So we went back to the basics, and used standard ellipse formulae to find out whether a particular point lies in the ellipse or not.
Conclusion
The product we created simulated the redlining feature well. Such a product should be very useful in the following cases:
- Users can give demos of their files in the field or the client's place, and can mark any changes immediately.
- Users can carry a HPC loaded with the CADD files, and not worry about the platform in the place of demonstration.
- Users can transfer the changes marked in the field to the main pc since the "_dwg" model is the same for both versions of Dr.DWG.