posted 10-12-2006 02:10 PM         

When I put a routine just before or just after the "#If %EZ_NOSKIPCODE code block" with the "'<<SAVE>> and '<<END>> macros" the Smart Parser deletes that code.

If put a routine just before or just after the "#If %EZ_NOSKIPCODE code block" without the '<<SAVE>> and '<<END>> macros the code is moved to the "#If %EZ_NOSKIPCODE code block" as expected.

If this is not by design then maybe there are other areas in the code that do not respond properly.

Comments Please -

posted 10-12-2006 02:46 PM         

Let me explain more clearly.

The Smart Parser reads all the source code of both the newly generated code and the previous source code.

It creates a table of SUBs/Functions. Each one is treated as a unique block of code.

All the code before a SUB or FUNCTION (obviously it is not another sub or function, but only code that can appear between subs or functions) is considered part of that block.

Code after the last SUB/Function will be lost, because it is not associated with a sub or function, so don't put any there.

The only exception to this is EZ_Main, where no code is to be put before it, since the designer must generate its own code before it. (the code tags can be used here to prevent removal of any type of code).

When the designer compares the two tables of code blocks, it finds all the subs that exist in the newly generated code which also exist in the previous code and leaves them alone (plus it adds any news ones generated).

Any subs or functions from the previous code which do not exist in the newly generated code are considered obsolete. The designer assumes they are for forms or controls removed during form editing.

So how does one keep any user defined subs/functions they write ?

You put them in front of any sub or function, except EZ_Main and then surround them with the '<<SAVE>> / '<<END>> macros !

The smart parser will then consider them non-subs/functions and they will be kept with the sub that comes immediately after the '<<END>> tag. They won't be moved.

You don't need the macro tags for non-sub code before code generated subs/functions. You just need them for user defined subs/functions.

All other code which the designer finds (ie user defined subs/functions or obsolete subs/functions) will be moved to the

#If %EZ_NOSKIPCODE section

so they won't get compiled. You don't lose the code, it just is removed from being compiled by the compiler directives.

The only time code can be lost be the smart parser is if it is put after the last sub/function and before the "#If %EZ_NOSKIPCODE compiler directive. The code is not associated with any subs/functions.

This means any code after the last sub will be lost. By using the macro tags around subs/functions after the last generated sub, the smart parser does not consider them subs/functions. Thats what the tags accomplish. Because of the tags, the parser just sees non-sub/function code after the last sub/function and as stated, it is removed.

I recommend putting all user defined subs/functions before the events procedure for the form they will be associated with (remember the code tags). You can also put them in an include file too.

While this may seem a little confusing, please remember that merging new code with previous code is not an easy task. I had to set up some rules to go by, and treating all subs/functions (with any code in front) as blocks was the only way to make the smart parser work.

Just remember the rules:

(1) Don't put user defined subs/functions before EZ_Main or after the last generated sub/function.

(2) Put all user defined subs/functions before one of the existing generated subs/functions and surround them with code tags.

(3) non-sub/function code does not require code tags.

(4) all non-sub/function code and user defined subs/functions (within code tags), are considered part of the first code generated sub/function after it. The parser keeps then together.

(5) all sub/functions found in previous source code which don't have a matching sub/function (unless within tags) in the newly generated code, are consider obsolete routines and will be placed in the skip code compiler directive at the end. You must manually delete this code.

posted 10-12-2006 03:25 PM         

While experimenting with where to put code, with or without the save macro, I did put a routine with the save macro before EZ_Main and everything worked just fine. Without the save macro the code was put in the %EZ_NOSKIPCODE code block.
(Top of program to bottom of the non-tagged subroutine)

Thanks for the clarification.

BTW - I am about halfway through the help file and the codeclips. I am very happy with what I have seen so far.

Worth every penny.

------------------
Trento Castricone
trento@castricone.com

posted 10-13-2006 01:19 PM         

Using - EZ_ShapeFormToPicture - I need to replace this:

' ======================================
' [PROTECTED CODE] Do NOT Edit !
' ======================================

SUB EZ_Form1_Display(BYVAL Parent$) ' (PROTECTED)
EZ_Color -1, -1
EZ_Form "FORM1", Parent$, "My Dialog", 0, 0, 156, 48, "^_C"
END SUB

With my EZ_ShapeFormToPicture sub routine.

How can I keep the call to the - EZ_ShapeFormToPicture sub routine - from being over written?

posted 10-13-2006 01:34 PM         

To accomplish this, first use a basic bitmap for designing your app. Once you have things working the way you want, then change the form so it is not using a shape. The EZ_ShapeFormToPicture code will be removed by the Designer.

Now in the forms event code, process the %EZ_Loading event (which occurs before the EZ_Form command is actually executed). Call the EZ_ShapeFormToPicture command in this event. You can delete the original bitmap in the forms %EZ_Loaded event.

ie.

code:

SUB MPLAY_Events(CID&, CMsg&, CVal&, Cancel&)
     STATIC PN$
     SELECT CASE CID&
          CASE %EZ_Window
               SELECT CASE CMsg&
                    CASE %EZ_Loading
                         PN$=EZ_LoadPicture("mediabg.bmp")
                         EZ_ShapeFormToPicture PN$, -1
                    CASE %EZ_Loaded
                         EZ_FreeImage PN$
                    CASE %EZ_Started
                    CASE %EZ_Close
                    CASE ELSE
               END SELECT
          CASE ELSE
     END SELECT
END SUB

posted 10-13-2006 01:53 PM         

It is for cases like this, which I added the new events %EZ_Loading and %EZ_Loaded.

In all the commands which create forms or controls, EZGUI calls an internal routine which generates the %EZ_Loading event when needed. In the Designer simply select the "Allow %EZ_Loading Event" option and the necessary code to generate this event is generated (call to EZ_AllowLoadingEvent command).

EZGUI generates %EZ_Loading before a form or control is actually created.

There are support commands which allow you to retreive or change the parameters passed to the EZ_Form or control creation commands.

They are:

EZ_GetLoadStr
EZ_GetLoadVal
EZ_SetLoadStr
EZ_SetLoadVal

These commands allow you to make changes to form or control creation dynamically via code, without having to change the actual code in the protected routines.

In the old days (EZGUI 3.0) it wasn't a problem because you could edit any code you wanted. The real problem then was that once generated you couldn't go back and forth between the designer and code editor.

Now with EZGUI 4.0's Smart Parser and the ability to regenerate code, some code blocks had to be off limits for it to work. By adding these events (and commands to support them), you can still make changes to form control creation dynamically, but you have to do it within an event now, rather than directly in the forms display or deisgn code.

If you examine the generated coded by the new designer you will notice a number of things that were added simply for the sake of allowing you such dynamica customization.

The Main_Initialize function is so you can add code during EZ_Main, without actually writing code within it.

The OtherForm_Events procedure is so you can process events for forms not created by the designer, without actually modifying code within EZ_Events.

The OtherForm_Design procedure is a compliment to this so such dynamic forms can be designed.

The PreProcess_Events function is so you can preprocess events before they are parsed out to the forms, without having to modify the actual EZ_Events code.

You will even notice in the forms _ParseEvents routine the select case else section looks like this:

code:

          CASE ELSE
               MYFORM_Events CID&, CMsg&, CVal&, Cancel&

Why ?

This is so control ID's unknown to the Designer (because they are created dynamically via code), can still be processed. If an ID is not one of the existing controls created by the designer, the events are passed back to the forms private event procedure (and its ID), so you can write event code for it.

Some procedures had to be protected from user editing so the Smart Parser would work. I simply added other places for you to be able to write dynamic code, so this would not be a limitation.

The more you work with this, the more you will appreciate how much forethought went into determining what new events or user editable procedures were needed to support the Smart Parser, so as not to limit what you can do.

posted 10-13-2006 02:14 PM         

%EZ_Loaded occurs for a form after the controls on it are created, but the form is not visible yet.

Forms also get one more event, which is %EZ_Started. This event occurs after the form is created, its controls are created and the form is actually visible. In the past one would have to post events to get them at this point, but now there is an event just for this need. Things like threads or timers can be created in this event.

It is very important to grasp the concept of Events in EZGUI 4.0 ! Unlike DOS apps where everything is quite linear in design, EZGUI apps have all sorts of available events. The big question is whether there is an event for what you need.

Simply ask yourself the question when would I want this to occur ?

Then see if there is an event available for this !

It is beneficial to take time to browse all of the events in the Events section of the docs.

The SEARCH feature of the help file is very useful here.

For example, let's say you are working with the Treeview control. Maybe you aren't sure what events are available for it. Type in the words treeview and event (ie. treeview event) in the search text and then click "list topics".

The following events will be listed (among some other topics too):

(note: the events don't have the % character in the topic name, since help files don't allow this)

%EZ_Selected
%EZ_UnSelected
%EZ_AllowEdit
%EZ_DragItem
%EZ_Expand
%EZ_NoCustomDraw
%EZ_Collapse
%EZ_CustomDraw
%EZ_DragItemDrop
%EZ_DragItemID

also EZ_StartDragDraw command references %EZ_DragItemDraw event

By seeing what events may be available, one may see more ways to accomplish what you want.

It should be noted though that this method of searching may not show all possible events for a control. For example some events are generic among many controls (ie. %EZ_Click) and the docs may not make specific reference to specific controls.

This should though find most of the events unique to specific controls.

It should be noted that many of the Common controls get the following events:

%EZ_Click
%EZ_DClick
%EZ_Focus
%EZ_NoFocus

posted 10-13-2006 02:26 PM         

Everything works !