|
This page is updated very often, so click 'Reload' button in your browser to get fresh version! |
Why Windows applications so large and so fat?
Its very simple. All these contain too many code and resources that
are not really needed to provide its functionality. For example, in Delphi we usually
start new project with a single empty form. If we build this project we can see that size
of program that yet do nothing is already more than 100K bytes. And it is only needed to
provide some carcass and then during further programming code will growing more. Finally,
after creating something sensible application that can do whatever You will got at least
300K bytes in the best case! (Yes, I know, that after building it with run-time
libraries it is collapsing to several kilobytes, but using this method You need to
distribute at least one dpl or bpl file with size more than 1Mb with such "tiny"
application).
And why it is so? Why this unnecessary code is attaching to application
while building it? Because of linker (which is existing in Delphi too) is attaching code
of all units, which names are referenced in already added units.
How to make small applications for Windows in Delphi?
Answer not too complex. First refuse from using VCL (and forms in
particular). Use only Windows.pas, ShellAPI.pas and Messages.pas. Call only API functions.
If You want use some powered objects (lists, stringlists, inifiles and so on) be careful.
Test size of Your application before and after including new unit to USES clause of Your
project. If growing is too big, refuse from it, and think: if You can not create similar
unit with only required functionality support? If You can, do it so. Do not afraid!
Windows API contain all You need. But...
Yes, I know it is not convenient. Refusing from VCL and the most of
powerful objects provided by Delphi makes programming very hard and very slow. Often You
already forgot (or even did not know) about several API calls. If You started Your carrier
in Windows from Delphi, all these are hard twice. As a result You have to reduce
additional functionality of your small apps made without VCL, simplify their behavior and
got too poor code which without doubts looses in comparison with similar Delphi powered
applications - even in their exterior look.
How to create good programs without VCL?
All You need to create good programs is a good library of objects
suitable to provide You with all services You want to have. TObject class is not bad basic
to create clever objects that therefore do not need too many code and keep Your program
size in reasonable limits. Indeed, growing of code when using VCL starts with TPersistent.
This last is the ancestor class for most of VCL components. It is intended to provide
Delphi VCL components and controls with ability to read their initial state from the form
definition block located in executable. Refusal of VCL is first of all refusal of
TPersistent. Because all components are descendents from TPersistent You can not use
forms, components and controls. But controls what You usually use are not the part of
Delphi. These all are part of Windows and Delphi only provides pleasing object-oriented
interface with them. It is possible to provide similar object-oriented interface with all
Windows controls such as button, label, edit, toolbar, and so on by hand just creating
correspondent object class. And if it is programmed it can be re-usable not only by You
but by anybody in the World. I think that it is not work for single programmer. So...
Let us start XCL project and reduce code size of our applications!
By given document I (Mr.Bonanzas) declare start of OPEN FOR ALL eXtreme Class Library project. Anybody who wants to join this project can contact me. I will provide members list of this project on my WEB page (here). Anybody who have ideas, suggestions and necessary experience is invited. Welcome to XCL!
![]() |
XCL is freeware at all. In part, this means that nobody can sell it for any kind of charge. Anybody can use it for creating products of any kind, including commercial software products without any restrictions. As it is said usually in License Warranty Agreement,
"In no event shall the
author be held liable for any damages whatsoever,including without limitation, damages for
loss of business profits,business interruption, loss of business information, or any other
loss arising from the use or inability to use the software."
I can definitively say: NO. XCL controls even more power in some cases.
Moreover, XCL allows to solve of some problems of exterior in Delphi applications, which
could not be solved in VCL at all. E.g., it is a problem of flickering, which can be
solved in XCL using add-ons. And, it is a problem of autosizing of forms (solved using
add-ons) and proper scaling of those. And, it is a problem of appearing/disappearing of
scrollbars, problem of resizing of thumb-button on scrollbars and problem of flickering of
scrollbars. I can also add here, that many problems, which are interesting for beginners
(e.g.: how to hide app from taskbar, how to rotate fonts), can be solved in XCL much
easier then in VCL - just with one line of code.
Oh, I forgot to mention the greatest problem - size of executable... In XCL
it is solved too.
Last updated: 26.09.99
'eXtreme' because it consists of objects not components. So application made with its
can be eXtremely small.
'Class' because it is intended to provide interface with standard Windows controls such as
button, checkbox, listbox, treeview, richedit and other Microsoft Foundation Class
objects. Also it provides similar objects which are not windowed and not based on MFC like
graphic controls in Delphi VCL. These all are needed to provide normal programming
environment and in most cases too overloaded in Delphi with code which often are useless.
For example, if You use TStringlist without sorting possibility code which provide this
unclaimed feature will be added in any case and You can not refuse from it. And so on.
'Library' because it is must be FREE for use by anybody in the World who want use it. All
members of XCL project must be agree what their code will be available with source for
anybody who want to use it (not end application - that is out of the question). Only in
that case still possible to improve this project and include new members.
First, You have to get acquainted with agreements above. Then, You can download xcl.zip which contains XCL project sources at the current state. Then if You find it possible for You, join us (me)!
Look at the task list and choose kind of problem what You can solve. Then e-mail me. After joining Your name will appear in members list and in task list. After finishing task You choose another task and so on. But work what You finished sometimes may require Your attention. You have to stay responsible for all corrections in your code. If You can not continue work with XCL or become busy for a time but your code need to be fixed or improved this work can be re-entrusted to another member of our project. Remember, that our association is free and voluntary union of programmers who agree to listen up another opinions, take and give advises, make and receipt suggestions, take part in any discussions concerning this project.
XCL programming basic principles.
Any object designed for eXtreme Class Library must satisfy to the following concepts:
Here You can see members of XCL project and data what they found
possible be published about them. Also, in right columns You can see tasks that are made
by them and current job of every member if he(she) working under. If You have questions or
suggestions to particular member concerning task for which he is responsible You may
contact him(her) directly if e-mail is available ( if not, contact me ).
Names of base (usually abstract) classes are italicized, end
classes intended to use in applets have bold names.
Member name |
Tasks finished |
Current task |
Vladimir Kladov (Mr.Bonanzas) | XClass, XVisual , ZList, XWindow
(+XWindowsManager), XApplet (modified by C.Kok), XForm (+XFormsManager),
XFormAutoSizer, XControl, XControlAutoPlacer, XGraphics.pas
(XPen, XBrush, XFont), XCanvas
(+XCanvasManager), XCanvasObjectsManager, XControls.pas
(XCustomControl, XLabel, XCustomBevel, XBevel,
XPanel, XSplitPanel, XStatus, XSplitSizer, XGrep, XGroup,
XPaint, XCustomCheckBox, XCheckBox, XRadioBox,
XCustomCheck, XCheck, XRadio, XCustomButton,
XButton, XDropButton, XScroller, XScrollBar, XScrollBox), XTimer,
XMenu, XResizeAntiFlicker, XEdit (+4 add-ons); XMfcControl and its descendents: CCustomStatic, CLabel, CCustomPaint, CPaint |
thinking... |
C.Kok | Useful modifications of XApplets.pas allowing to minimize/restore XCL applet using its taskbar button pop-up (system) menu. | |
Your name here | Task for You | |
XEdit, cPanel, cButton, cGroup, cCheckBox, cRadioBox, cEdit, ... |
Here You can see list of available problems to solve named 'tasks'.
If problem is solved or it is solving now then name of member is appearing in right
column of table below. Any case name of task in left column is referred onto more
detailed description of this one in separate html (if such description is ready). You may
click it to read either project definition or final description if task finished. If You
feel that task list not full, feel free to e-mail me about it to suggest new necessary
task name and its brief and/or detailed definitions.
Choose one of not allocated problems to become a member or if You
consider that task list is not complete, add your own here. Feel Yourself free to use
source of any solved task similar given to get a template to solve any other. If You give
task be remember that Your code must satisfy to basic principles
of XCL project. E-mail me, if
You are ready to vote yourself as XCL developers team member.
Task name |
Task description |
Status |
XClass and XChild in XClasses.pas |
Similar TComponent in VCL. But it is descending from TObject and differ from this last mainly by ability to have parent XClass object and list of child XClass objects. Parent is responsible for destroying of childs when it is destroyed. | finished by Mr.Bonanzas - 16-Jun-99 |
XVisual in XVisuals.pas |
Ancestor of XWindow and XControl. Intended to provide XForm (->XWindow) and XControl with common virtual methods and properties (BoundsRect, ClientRect, Visible, Enabled and so on). | finished by Mr.Bonanzas - 16-Jun-99 |
XWindow in XWindows.pas |
Similar TWinControl and TForm in VCL. Provides registration of window in Windows environment and basic functionality of it (message handling, creating, destroying). | finished by Mr.Bonanzas - 16-Jun-99 |
XApplet in XApplets.pas |
Similar TApplication in VCL provides running of applet, interface with main window, loop of messages dispatching. | finished by Mr.Bonanzas - 16-Jun99 |
XForm in XForms.pas |
Similar TForm in VCL but without reading
itself from executable. Just XWindow with ability to have XControl objects as childs.
Responsible for painting, focusing, mouse and keyboard events handling. In contrast to VCL TForm, is simplified by avoiding of support of printing form, responding for MDI, scaling, aligning of controls. And at least it can not read itself from executable. |
finished by Mr.Bonanzas - 18-Jun-99 |
XFormAutoSizer in XFormAutoSize.pas |
Add-on module for autosizing of XForm and its descenders and XControl descenders with child controls. It is adding by calling of UseAutoSizer increasing applet for several Kbytes. | finished by Mr.Bonanzas - 19-Jun-99 |
XAligner in XAlign.pas |
If used in applet (by calling UseAligns),
adds for all XForm(s) and its descenders support of Align property for all its child
controls, which are using this one. If this add-on is not used, executable become smaller for about 3Kbytes. |
finished by Mr.Bonanzas - 19-Jun-99 |
XResizeAntiFlicker![]() in XResize.pas |
This add-on when used (by call
UseResizeAntiFlicker) eliminates flickering of controls aligned to opposite side to moving
with mouse border edge during x-form resizing. There are no similar solutions for VCL, and
I think this task can not have solution in Delphi VCL in common case at all. Even in XCL
ResizeAntiFlicker works better for forms without MFC-based controls (and in VCL the most
of controls are MFC-based). When used, increases size of executable by 4Kbytes. |
finished by Mr.Bonanzas - 05-Sep-99 |
XFormsStdMouseEvents in XMouseEvents.pas |
Add-on for XForm for handling mouse events. It is included into final executable only by calling UseStdMouse adding about 1Kb. | finished by Mr.Bonanzas - 02-Jul-99 |
XFormsStdKeyEvents in XKeyboardEvents.pas |
Add-on for XForm adding keyboard handling and tabulating between controls. It is added to executable only by calling UseKeyboard increasing size of applet onto about 1,5Kb. | finished by Mr.Bonanzas - 02-Jul-99 |
XControlAutoPlacer in XControlAutoPlace.pas |
If used, it adds for all XForm(s) support of autoplacing and autoresizing controls when size and / or position of its childs are changed. This allow to adjust size and position of controls and form itself so its never overlaps and form always is shown correctly independently of screen resolution, font sizes and so on. | finished by Mr.Bonanzas - 19-Jun-99 |
XControl in XForms.pas |
Similar TGraphicControl in VCL. In XCL it is a descendent of XVisual. Created as a child of XForm, which simulates focusing and provides device context for it while painting. | finished by Mr.Bonanzas - 18-Jun-99 |
COMMON UTILITIES | ||
ZList in XClasses.pas |
Similar TList in Delhi VCL, but more simple (does not not support sorting, has no Move or Swap methods). | finished by Mr.Bonanzas - 16-Jun-99 |
ZTimer,
XTimer in XTimers.pas |
Objects to encapsulate Windows timer. Similar to TTimer in VCL, but ZTimer and XTimer are using applet button window and handles messages directly. ZTimer is derived from TObject so You are responding for its freeing. XTimer can be child of any other XClass (in that case it is destroying when its parent is freeing). | finished by Mr.Bonanzas - 02-Jun-99, 27-Jul-99, 08-Sep-99 |
XMenu, XPopup in XMenus.pas |
Similar to TMainMenu and TPopupMenu in VCL. But very simple. These two classes allow to create easy statically designed (as a list of strings) menu with submenus. | finished by Mr.Bonanzas - 27-Jul-99 |
ZStrList in XStrLists.pas |
Similar to TStringList in VCL. | finished by Mr.Bonanzas - 14-Sep-99 |
XStrUtils.pas | Set of necessary string utility functions. | finished by Mr.Bonanzas |
XDateUtils.pas | Set of functions to work with date and time. XDateTime in XCL made slightly another (days are counting from 30-Dec-0001 B.C., not from 30-Dec-1899 A.D. as it is made in VCL). | finished by Mr.Bonanzas - 25-Sep-99 |
XFileUtils.pas | Set of functions to work with files. Only XFileExists function now available. | finished by Mr.Bonanzas |
HIGH-LEVEL GRAPHICS SUPPORT | ||
XGraphicObject,
XPen, XBrush, XFont, XGraphicsManager in XGraphics.pas |
Basic graphics objects and other definition. Primarily these are used with XCanvas, but can be used separately. | finished by Mr.Bonanzas - 20-Jun-99 |
XCanvas,
XCanvasManager in XCanvases.pas |
Similar TCanvas in VCL but smaller and more simple. It does not avoid duplicating of resources but it is intended to paint mainly on WM_PAINT message and this ability is not necessary. At least, it is possible to use additional XCanvasObjectsManager to reuse resources at the expense of increasing code. | finished by Mr.Bonanzas - 20-Jun-99 |
XCanvasObjectManager in XCanvasObjects.pas |
Intended to expand XCanvas with ability to void of duplicating resources and reuse it from heap. If it is not used, executable can be smaller. It is recommended to use it if applet is performing a lot of painting or have big number of controls - to reduce needs in GDI resources. | finished by Mr.Bonanzas - 20-Jun-99 |
XFontRotator in XRotateFonts.pas |
This add-on is intended to allow painting of rotated text (in XLabel and other controls, using XLabel). Setting property Orientation of XFont object is not sufficient to paint rotated text correctly. FontRotator calculates correct size of area to place rotated text and origin point to pass it to Windows.TextOut function. | finished by Mr.Bonanzas - 20-Jun-99, 19-Jul-99 |
SELF-PAINTING
CONTROLS These controls require XCanvas and perform painting and other controlling itself, using only API calls. So, size of applet using such controls, is greater then in case of using MFC-based controls only (see below). But is You want to get some effects (e.g. rotating font in labels) or to replace some standard controls with more efficient, this is your choice. All the more self-painting controls do not require window handle, so needs in user resources can be reduced using these ones.
|
||
XCustomControl in XControls.pas |
Prototype of self-painting controls, which use canvas of parent form. | finished by Mr.Bonanzas - 22-Jun-99 |
XLabel in XControls.pas |
Simple self-painting label similar to TLabel in Delphi (but can not WrapWords and to be transparent). | finished by Mr.Bonanzas - 22-Jun-99 |
XCustomBevel in XControls.pas |
Prototype of beveled controls (panels, buttons and so on). | finished by Mr.Bonanzas - 23-Jun-99 |
XBevel in XControls.pas |
Simple panel without caption, beveled as default with raised 3D-frame. | finished by Mr.Bonanzas - 23-Jun-99 |
XPanel in XControls.pas |
Panel very like to TPanel in Delphi. Uses internally XLabel to draw caption. | finished by Mr.Bonanzas - 24-Jun-99 |
XSplitPanel in XSplitPanels.pas |
Panel, divided onto several inner panels. This control
requires XAligns add-on and necessarily includes this last into executable. Inner panels
can be sized with mouse if add-on XSplitSizing is used (call UseSplitSizer). Inner panels ( which are derived from XPanel ) can be put vertically or horizontally, from left/top to right/bottom or from right/bottom to left/top (the last of inner panels is client-aligned, so Side property determines which panel will resizing with form - first or last). |
finished by Mr.Bonanzas - 31-Jul-99 |
XStatus in XSplitPanels.pas |
Status bar similar to VCL TStatusBar but even more power if add-on XSplitSizing is used (in that case inner panels can be sized with mouse). | finished by Mr.Bonanzas - 31-Jul-99 |
XSplitSizer in XSplitSizing.pas |
Add-on, allowing splitting of XSplitPanel and its descendents (i.e., XStatus). | finished by Mr.Bonanzas - 31-Jul-99 |
XGrep in XControls.pas |
Special control to draw grep in bottom-right corner of parent control (usually panel, status inner panel or any other XCustomBevel descendant). Also provides response to WM_NCHITTEST message, growing area where cursor becomes NW-SE and sizing of form is possible. | finished by Mr.Bonanzas 31-Jul-99 |
XGroup in XControls.pas |
Similar TGroupBox in Delphi. Can have title on any part of border. | finished by Mr.Bonanzas - 25-Jun-99 |
XPaint in XControls.pas |
Simple self-painting control with OnPaint message (similar to TPaint in Delphi VCL). | finished by Mr.Bonanzas - 25-Jun-99 |
XCustomCheckBox in XControls.pas |
Prototype for checkboxes and radioboxes. | finished by Mr.Bonanzas - 26-Jun-99 |
XCheckBox in XControls.pas |
Simple checkbox without caption. | finished by Mr.Bonanzas - 26-Jun-99 |
XRadioBox in XControls.pas |
Simple radiobox without caption. | finished by Mr.Bonanzas - 27-Jun-99 |
XCustomCheck in XControls.pas |
Prototype for XCheck and XRadio (look below). | finished by Mr.Bonanzas - 27-Jun-99 |
XCheck in XControls.pas |
Checkbox with caption similar to VCL TCheckBox. | finished by Mr.Bonanzas - 27-Jun-99 |
XRadio in XControls.pas |
RadioBox with caption similar to VCL TRadioBox. | finished by Mr.Bonanzas - 28-Jun-99 |
XCustomButton in XControls.pas |
Simple button without caption or picture. It is intended mainly as prototype of button but therefore can be used itself. | finished by Mr.Bonanzas - 29-Jun-99 |
XButton in XControls.pas |
Simple button with caption. Can be fixed, focusable or speed button, autosizable, aligned, ... | finished by Mr.Bonanzas - 30-Jun-99 |
XDropButton in XControls.pas |
Simple button to represent drop (up, down, right, left) triangle arrow. | finished by Mr.Bonanzas - 01-Aug-99 |
XScroller in XControls.pas |
Similar to TScrollbar in VCL and even more power. | finished by Mr.Bonanzas - 28-Aug-99 |
XScrollBar in XControls.pas |
Similar XScroller, but more specialized to work in pare with another scrollbar on the same parent control. | finished by Mr.Bonanzas - 28-Aug-99 |
XScrollBox in XControls.pas |
Similar TScrollBox in VCL. It allows place into and scroll other controls. | finished by Mr.Bonanzas - 30-Aug-99 |
XEdit in XEdits.pas |
Similar TEdit in VCL. | finished by Mr.Bonanzas - 08-Sep-99 |
XCaretShower in XCarets.pas |
Add-on providing the painting of blinking caret
in edit controls which are derived from XCustomControl (like XEdit) and has no window
handle. It does not use Windows' caret APIs, instead it paints caret itself what requires
about 1Kbytes of code, but is looking more correctly when controls are overlapped and
requires nothing when not used. Activated by call UseCaret( True ). Can be deactivated at run time. |
finished by Mr.Bonanzas - 08-Sep-99 |
XEditMouseSelect in XEditMouseSel.pas |
Add-on to provide selecting of portions of text in XEdit control with mouse and to scroll its content with mouse. | finished by Mr.Bonanzas - 08-Sep-99 |
XEditClipboard in XEditClipbrd.pas |
Add-on to provide copying/cutting selected part of XEdit text to clipboard and pasting from clipboard to XEdit. | finished by Mr.Bonanzas - 08-Sep-99 |
XEditUndo in XEditUndoExt.pas |
Add-on to provide undo/redo operations for XEdit on pressing CTRL-Z, CTRL-SHIFT-Z or by calling appropriate methods. | finished by Mr.Bonanzas - 10-Sep-99 |
XCustomGrid in XGrids.pas |
Similar to TCustomGrid in VCL but lighter. | finished by Mr.Bonanzas - 12-Sep-99 |
XGrid in XGrids.pas |
Similar to TDrawGrid in VCL but lighter (no fixed rows and columns). | finished by Mr.Bonanzas - 12-Sep-99 |
XListView in XLists.pas |
Similar to TListBox in VCL (without editing). | finished by Mr.Bonanzas - 14-Sep-99 |
XListMouseSelect in XListMouseSel.pas |
Add-on which allows mouse positioning, selecting and scrolling for XListView. | finished by Mr.Bonanzas - 14-Sep-99 |
XListKeySelect in XListKeySel.pas |
Add-on which will allow positioning, selecting and scrolling of lines in XListView with keyboard. | finished by Mr.Bonanzas - 15-Sep-99 |
XListEdit in XListEditExt.pas |
Add-on to provide editing lines of XListView using temporarily created XEdit control. | finished by Mr.Bonanzas - 16-Sep-99 |
XNotebook in XControls.pas |
Similar to TNotebook in VCL. Allows to place children controls on several Pages[], only one of which last (ActivePage) is visible at the time. | finished by Mr.Bonanzas - 20-Sep-99 |
XTabs in XControls.pas |
It seems to be like as TTabControl but slightly different in appearance and behaviour, especially in case than a lot tabs are needed to be shown. I think, my solve of this task more complient then in VCL. | finished by Mr.Bonanzas - 20-Sep-99 |
XTabbedNotebook in XControls.pas |
It is the union of XTabs and XNotebook, where XTabs is controlling ActivePage of Notebook and can be placed at one of four sides of the last. | finished by Mr.Bonanzas - 20-Sep-99 |
XCalendar in XCalendars.pas |
Similar TCalendar in VCL. Can be horizontal or vertical - oriented, first day of week can be changed from Sunday to other (e.g., Monday), and some other features make it even more power (then TCalendar). | finished by Mr.Bonanzas - 26-Sep-99 |
MFC-BASED
CONTROLS
These controls are very important, because it is
very easy to create it just constructing interface with existing (globally in Windows)
control classes. These classes are located in standard DLL's, which are supplied by
Windows itself. And these are painting and controlling itself, so code of Mfc-based
controls is very small, and applet can use large set of those without great growing of
size of executable.
|
||
XMfcControl in XMfcControls.pas |
The prototype for all Mfc-based controls below. Derive new Mfc-based controls from it. | finished by Mr.Bonanzas - 19-Jul-99 |
XWCustomStatic in XMfcControls.pas |
The implementation of 'STATIC' control. Needs in further detailization. Potentially can be ancestor of static text label, static bitmap/icon image or event play role of panel with bevels. | finished by Mr.Bonanzas - 19-Jul-99 |
CLabel in XMfcControls.pas |
Derived from XWCustomStatic, is presenting natural Windows label (similar TStaticText in Delphi VCL). If You plan change it often, use anti-flickering add-on below. | finished by Mr.Bonanzas - 19-Jul-99 |
XWCustomPaint in XMfcControls.pas |
Prototype of owner-painting controls. Implemented next after XWlabel to derive XMfcCover (local in XMfcAntiFlick.pas). This last was required to cover XWLabel temporarily and prevent flicks in WM_SETTEXT message. | finished by Mr.Bonanzas - 19-Jul-99 |
CPaint in XMfcControls.pas |
Derived from XWCustomPaint. Similar to TPaintBox in VCL. | finished by Mr.Bonanzas - 19-Jul-99 |
XMfcAntiFlicker in XMfcAntiFlick.pas |
Add-on to avoid flicks in Mfc-based controls:
(1st) by painting through memory bitmap buffer; (2nd) by preventing changing of caption
during assignment new one. Just call procedure UseMfcAntiFlicker before creating the first form in dpr-file (as well as for other add-ons). Size of code added there is about 2 Kbytes. |
finished by Mr.Bonanzas - 19-Jul-99 |
XCL
TOOLS
This part contains definition of possible external tools which (could be) made using standard VCL. Such utility applications could be used to simplify programming in XCL which is not now "visual" process and seems to be harder then working in IDE. As it is said in introduction, we have to refuse from such IDE beauties as visual form designing using Components Palette and Object Inspector. But this does not mean that it is impossible to create wizard, which could play role of these great tools. Such wizard could allow to design XCL forms and adjust its controls properties and events making XCL-plogramming visual and convenient again. |
||
XCLDesigner.exe | Tool, which allow to preview XCL form, drop
controls onto it, inspect and change its properties and events similar to how IDE shell
does for standard VCL form. Designer takes definitions of controls from its source (may be, taking some of those from comments). In result designer has to generate source for dpr-file and project units. It would be pleasure if the Designer could work interactively generating source code immediately in correspondance with performed commands similar that IDE does. |
??? |
Here You can see hierarchy tree of ready to use XCL controls.
Even if You are not a member, but just use or plan to use XCL in your work, You may
refer to this page using banner above. Just place it on your page with reference to my
page either
(1) by copying and pasting banner above onto your page;
(2) or by inserting following html into your page html:
<a href=http://members.xoom.com/mr_bonanzas/xcl/xcl_frames.htm" target="_blank"><img src="xcl_vs_vcl.gif" width=80 height=40 alt="XCL vs VCL. Let us make our Delphi programs small !" border=0></a> |
Here You can download last version (v1.50 from
26-Sep-1999) of XCL in xcl.zip.
I found that some developers can not immediately get desirable effect of reducing executable by using XCL or even compile project without errors. May be it is because they did not pay attention to some important info. May be it is because such info is located by parts in different places of this documentation. Here I will try to concentrate references to such significant info, calling its as 'lessons'.
16-Jun-99 | - XCL project has started. This document had written (but not published
yet), ZList, XClass, XWindow, XApplet are made. First applet with three windows and total
size 23,5Kbytes of executable.
|
20-Jun-99 | - unit XCanvases had written. Also unit XCanvasObjects is written too.
New technique of optional including additional modules extending functionality of basic
ones is applied, so applet can either include only XCanvases unit or XCanvases +
XCanvasObjects. Or canvases can be voided to include at all if only MFC based controls are
used.
|
03-Jul-99 | - Several self-painting controls are ready. This set of ready modules
allows to create some small utilities starting it from 60Kbytes and without fast
increasing of code while programming it. Now, I feel that I will busy with my family
during summer, so I decided to stop coding and make some efforts to create a few docs and
publish this my work on my page. Go and get it!
|
06-Jun-99 | - Documentation for XClass, XVisual, XWindow, XApplet and XForm is ready
and I decided to start publishing XCL. Didn't I too hurry up?
|
19-Jul-99 | - Very important news: XMfcControl class and first MFC-based control
XWLabel are finished. These required to make very serious changes in some base classes
(XVisual, XWindow, XForm, XControl). But after all that I could find time to fight with
flickering (I hate it, and I do know who love it - MS). In result add-on XAntiFlick.pas is
ready to stop flicks in MFC-based controls, and add-on XRotateFonts is extended to do so
with rotated labels. Something yet can be not finished, some bugs could be found, but I am going to go on leave and make holidays with my family (I will read mail at least ones a week and response as far as possible), so I am in hurry to publish all that made even without docs. I hope that some voluntaries from You will join to this project, and assist me in creating other MFC-based control.
|
23-Jul-99 | - I found a time to spend it to complete documentation. Also, banner of XCL is made, and You now can refer to this page from
yours if You like it. I still believe that You will not just watch, but join and take part
in creating of XCL...
|
27-Jul-99 | - Small changes are made in XMfcAntiFlick to work with anti-flick more
strongly when add-ons XControlAutoPlacer and XFormAutoSize are active too. Now there are
no flicks at all for MFC-controls. Also I decided to alternate names for MFC-based
controls using prefix 'C' instead 'XW'. So, XWLabel becomes CLabel, XWPaint becomes CPaint
and so on. Also new XMenus unit is added to library with two new classes XMenu and XPopup.
|
29-Jul-99 | - Some small bugs are found while working under XSplitPanel control. All
those bugs were affecting XAligns, XFormAutoSize add-on units and painting of
XCustomBevel. Very small bug found in XMenus.pas with showing of radioitems after first
checking (highlighting not removed). This was taking place only under Windows98. All found
bugs are fixed in xcl.zip located on my Web page. Starting from next version, I am going
to not place uploaded copy of xcl onto Torry pages to reduce number of re-registrations. I had registered as a member of Delphi Corner Web-ring. I hope, this will help me to notice more developers which could be interested in XCL.
|
31-Jul-99 | - Even more number of small and not too small bugs are found in add-ons
XAligns, XControlAutoPlace and XFormAutoSize while XSplitPanel and XStatus were debugging
and testing. Three new self-painting controls are ready: XSplitPanel, XStatus and XGrep. All XCL documentation files from this page are now available to download in a single zip, which will refreshing with the page. See bottom/top of this frame!
|
29-Aug-99 | - XScroller and XScrollBar are finished. Applets with only XScrollbar
component is already about 70K. But this yet smaller then VCL empty form. To show
dependency of application size and development time I placed a graphic
at the top of this page. - New small bugs were found and fixed. E.g., XSplitSizing.pas now works more carefully with sizing to right side of XSplitPanel of the first sizeable inner panel. XGrep now is created as alRight-aligned to prevent infinitive looping when FormAutoSize and ControlAutoPlace are using together. Key event is first passed to control which is capturing mouse. Capturing of mouse is improved and special method to XControl class is added. FormAutoSizer object has now property Collapse (default False) to let x-forms to become smaller than its controls are reducing its size (sometimes Collapse=True can lead to infinite recursion in autosizing and autoaligning). Some efforts are made in XFormAutoSize to allow autosizing of alClient, alRight and alBottom aligned controls. -
Also documentation for newly added classes is completed. And a couple of "typo"
discovered by one English teacher are corrected. Now Children property is substituting old
property
|
01-Sep-99 | Greetings again. With new version (1.41) bugs with
XScrollBar are fixed and now it is correctly scrolling all its child controls (of any
level) and mouse events are provided perfectly for scrolled objects. Also, priority for
handling mouse and for painting of XScrollBox scrollbars made highest. I had to make some
changes in XVisuals and XForms to do all these above. When XCL were only in project, I even could not suppose that ScrollBox can be useful. Now I am sure that it is really need to create scrollable self-painted controls similar TEdit, TListBox, T...Grid in VCL. You could ask me: why I spend so lot time to develop hard-working self-painted controls instead of improving MFC-based ones? Yes, creating of MFC-based controls is very easy. But my opinion still is that Foundation Classes are bugged, slow, overblotted, and have restrictions which are insuperable without creating of original controls. So I'd like to avoid of using MFC-based controls in my own applets and do not speed this brunch of XCL tree. If You want, You can make it easy and contact me. And, my congratulations to all teachers (even English language :-] ) and students with the start of new academic year!
|
05-Sep-99 | New cool add-on added to XCL -
XResizeAntiFlicker. It eliminates resize flickering almost at all. This mean that with
XResizeAntiFlicker turned on, when You move one of border edges of the x-form, all
controls, aligned to opposite side of this one, are standing like a stone image and do not
try to jump as rabbit. And, finally, XScrollBox is upgraded to restrict painting of scrolled child controls with client area of scrollbox. So, it is now done correctly. Also, focus drawing add-on is improved and now focus rectangle is non-flickering when other window is moving through it. New version 1.42 contains XApplets.pas unit, modified by C.Kok. Thanks to your assistance. Other: main page of my Web is simplified and is loading faster. |
08-Sep-99 | At last! XEdit is ready and XCL v1.43
becomes more power. Now it is not yet understanding undo, but functions to work with it
are ready. And this feature will be implemented as optional add-on, as well as for other
unnecessary parts of XCL. Even caret showing, selecting with mouse and clipboard
copy/cut/paste commands (these all are ready) are implemented as add-ons and can be
included or not to your XCL project. Also, ones more small bug fixed with dragging the scroller thumb button up/left. Small correction is made in ZTimer.Destroy method. And other small changes, what I do not remember. |
10-Sep-99 | The last of add-ons planned before for XEdit,
is ready: XEditUndo which allows to undo/redo editing operations for edit control. Add-on
XEditMouseSelect is improved to allow selecting with double click and corrected to work
properly with scrolled controls. Now I am starting the next great editing control XGrid (similar to TDrawGrid in VCL) and XStrGrid (similar to TStringGrid). I am going to derive later XListBox, XTextBox, XTreeView from these grid controls. I hope, that this will not contradict with the basic principle "not to reduce functionality while deriving new control from more power". Also I am investigating possibility of some changes in concept of constructing and painting of self-drawing controls. In particular, if it is more advisable to make inner controls to be normal children of combined control (or at least, store it in the same list and do not show in Children[] property for "users"). It seems could allow to reduce code of PaintTo method (or even eliminate it all) for some combined controls. Once more possible way of reducing code never leave me in peace. Every examining of the fact that a handler is assigned to an event of GlobalFormsManager, GlobalControlsManager and so on takes about 14 bytes of code. These examinations could be eliminated at all, but only in case if such events are always assigned to something. It is possible to assign them to dummy procedures (at the moment of creating Global...Manager variables) but creating of such dummy procedures and assigning its to events also takes some code. It would be wonder, if I could create the single dummy handler for all events, but these ones has different parameters number often... And Pascal demands that its number and types (signature) were equal. |
14-Sep-99 | Something similar to grid in VCL (XCustomGrid,
XGrid in XGrids.pas) and XListView
(similar to TListBox) are ready, so I have updated arhive on my site. The greatest
difference of XGrid from its VCL's mirror TDrawGrid is in that it is not understanding
fixed cols and rows. I think that the single optional fixed column/row will be added, but
no more, and in another class derived from it. XGrid and XCustomGrid in this
"light" status are very useful to derive XListView, which does not need in fixed
cols or rows. I spent a lot time to achieve discrete scrolling by columns and rows and
result is not looking great in some cases. May be, I will try to return to smooth
scrolling later or to make this discrete scrolling smooth with special add-on class. And
at least, I will return soon normal horizontal scroll of one-column grid (and XListView as
well). Working under XCustomGrid, I had to make serious changes in XScrollBox (the ancestor) and in XScroller/XScrollbar. But (I hope) this will not affect its own behaviour. |
16-Sep-99 | Add-ons XListKeySel.pas and XListEditExt.pas
are ready. Now lines of XListView can be edited.
XListMouseSel.pas add-on is improved to allow selecting a group of lines with SHIFT key.
XScrollbox, XCustomGrid and XListView are corrected to provide smooth scrolling in case of
single column/row of grid. I am planning XCombo on base of XEdit, XDropButton and XListView next. |
22-Sep-99 | New controls XNotebook, XTabs (similar to XPageControl, but with slightly another appearance
and behavior) and XTabbedNotebook are added to XCL
palette. Great efforts made to implement idea (10-Sep-99) of another imagination of internal (previously hidden and now 'member') controls. I hope, this leads to more easy creation of new controls (in future) and simplifies code. Unfortunately, I have not seen that exe becomes smaller but yet not all changes are made. Very interesting bug was found in 1.46 release due to code completion feature of Delphi: field FScrollOffset was inserted into private section of XScrollBox overriding existing protected one (inherited from XVisual). As a result, scrolled objects was not painted correctly after scrolling. In current 1.48 version this bug fixed and to prevent its new appearance, special private function intended to get FScrollOffset value. Also small bug fixed with finishing applet, containing the XScrollBar control (abundant calls to destroyers of child scrollbars are deleted). Very small change made in XListView to fix annoying appearance/disappearance of horizontal scrollbar while resizing in some cases. Also small change made to provide appearing / disappearing of such scrollbars simultaneously if this has to be done so. Attempt was made to implement idea listed 10-Sep-99 (above) to assign all the manager's events to dummy handler, but unsuccessfully. Size of exe was increased about 500 bytes even after deleting all the assignment tests, so I had returned the library to its previous state. I am planning to vote some next days to clean code and correct documentation in accordance with changes made through the XCL from its publication. |
23-Sep-99 | Some efforts are made to provide correct autosizing of
XSplitPanel and its successor XStatus. As You could see, I added last time method LoadFromFile to XListView. Now I tested it and added SaveToFile as well. Also, XIniFile class is added to provide easy working with ini files. I think, that my idea of using the same methods to both read and write allows to simplify code in case of fixed set of keys and sections and avoid most of errors when reading and writing of ini-file made in two different parts of code. |
26-Sep-99 | Fixed: Centering labels; Mouse events for controls on inner
panels of XSplitPanel; Initial width of XEdit made equal to 64 pixels; function
PointInRect corrected. New utility unit XDateUtils.pas is added to provide date/time operations. Type XDateTime differs from TDateTime of VCL in represantation of its value. Integer part of XDateTime is counting days starting from 30-Dec-0001 BC, not from 30-Dec-1899 AD, as it is done in TDateTime. For funs, I included function CatholicEaster (from Swags) there. New control XCalendar is added. I think it is even more power than TCalendar in Delphi. It can be horizontally or vertically oriented, it is possible to change first day of week (in some countries week is starting not from Sunday, but from Monday), font of buttons can be not the same as for digits (and rotated with Orientation property), day cells can be owner drawn with event OnPaintDay, events OnClickDay, OnClickWeekDay are provided, captions of weekday buttons are customizable and so on. |
![]() |
Idea of XCL Copyright (C) Kladov Vladimir, 1999 |