Author Topic: Macro Loading : List Synchronicity : User Macro Lists Incorrect during load/unlo  (Read 2492 times)

PurdueEEGrad

  • Senior Community Member
  • Posts: 115
  • Hero Points: -17
I am testing the current SE V19 release candidate - released 2014.10.28.

I have attached a test module (...test_04..) - to test user defined macro
load/unload operations. 

When I FIRST (1) loaded Test_04 (attached) Dialog [A] and [ B] (below) seemed OK.

(1) Load State : Test_04 Module loaded

[A] SE Menu -> Macro -> List User-Loaded Macros (dialog OK)

[ B] SE Menu -> Macro -> Unload Module (dialog OK)

(2) Load State : Test_04 Module UNloaded

[A] SE Menu -> Macro -> List User-Loaded Macros (dialog OK)

[ B] SE Menu -> Macro -> Unload Module (dialog OK)

The first time through : 1.A,B and 2.A,B seemed consistent.

--------------------------

I cycled Test_04 several times to ensure repeatablility (of the test) -
and ran into some problems (or what appears to me to be problems).

In a nutshell - After the First test run - Test_04 no longer showed up on dialog [A].

[1.A] SE Menu -> Macro -> List User-Loaded Macros  (Bad : dialog does NOT list Test_04)

Even though Test_04 shows up on dialog [ B].

[1.B] SE Menu -> Macro -> Unload Module            (Good : dialog DOES list Test_04)

--------------------------

When I unload Test_04, however - I now get the following problem.

[2.A] SE Menu -> Macro -> List User-Loaded Macros  (Good : dialog does NOT list Test_04)

[2.B] SE Menu -> Macro -> Unload Module            (Bad  : dialog DOES list Test_04)

After the module unload process - I expect that the module should NOT show
up on [2.A,B]. 

--------------------------

I have attached some screen shots that show - Test_04 loaded - and it
shows up on one dialog [1.B] - but not on dialog [1.A]. 

Furthermore - when I unload Test_04 - dialog [2.B] always shows Test_04 as
loaded. 

Perhaps there is a bug in the testcase (Test_04 attached) - that is
missing some API calls - that need to ensure synchronicity between dialogs
[A] and [ B]? 

Thought I would post this - to see if the attached test case code is
flawed (is Test_04 attached flawed).

--------------------------

Final note - It seems like the unload process does not remove Test_04 -
from the SE environment at all.  Is this by design? 

I can repeat the unload process again and again - via dialog [2.B] - and
get the same validation behavior - that show the Test_04 module is still
loaded - and can function - even AFTER a previous unload process has
completed. 

Perhaps I am missing something - in the way the SE Module paradigm should
work? Just in case - the following discussion explains the use case.

--------------------------

My concern deals with massive amounts of grep toolbars (60 to 100) - used
by large software development teams. Different code domains - require the
clean up of toolbars when - the user defined (code domain specific) SE
module is unloaded - and the user metaphorically exits that code domain.

So if I leave a MS XAML based GUI code domain - and enter a MS classic
windows GUI code domain - I no longer have grep toolbars specific to
XAML. The same thing goes for networking, threading, different OS and
different program language variations/permutations.

Note that some workspaces and applications are complex and 'heavy' by
nature. Many code domains (XMAL, threading, networking, advanced data
processing, 3D imaging and dataflow/workflow process automation - are
all rolled up into one heck of powerful application (enterprise level -
science and advanced data processing, etc).

For this caliber of software applications - having to switch workspaces
for the same application is NOT good. There must be a least one workspace
- that contains all the code in the application.

Additional SE workspaces may exist - to minimize the code space for
specific software programmers (newbies or contractors who only work
one aspect of the application - like threading or XMAL).

So ... I thought I should post this - in case this behavior is a real bug
in the SE release candidate.

--------------------------

Is the attached SE code module (Test_04) OK - or is it flawed?

PS. There seems to be some font issue (bold on) - when a posting
has [some_text] in square brackets such as [ B] vs without a space.

PurdueEEGrad

  • Senior Community Member
  • Posts: 115
  • Hero Points: -17
I retested the - user defined menu list synchronization problem - on SE
Release Candidate 2 (ie; SE V19 RC2). 

There is improvement - relative to the data synchronization bug : But -
There is still a problem with - some delete residue - after the delete
user loaded module step occurs (see test discussion below).  I have
attached a testcase (...V_04..) - along with some screen shots on what I
mean by 'delete residue'. 

Basically when a SE module is deleted - the file name of the module -
still comes up in the edit box of;

[]  Macro -> Unload Module :  Edit box at top of dialog - BAD : Shows delete residue

The test cycle is described below.

------------With Workspace-----

[X.1,2] = With a workspace loaded

Perform a load, delete, verify operation - using two different cycles of
operation. 

Test Cycle [X.1] : Load - Delete - verify - verify   

[1.1]  Macro -> Load Module  (V_04)

[1.2]  Macro -> List User-Loaded Modules : Then delete V_04 in this list

[1.3]  Macro -> Unload Module (verify V_04 is gone)   -  BAD : Shows delete residue in Top Edit box section

[1.4]  Macro -> List User-Loaded Modules (verify V_04 is gone)

Test Cycle [X.2] : Load - Delete - verify - verify   

[2.1]  Macro -> Load Module  (V_04)

[2.2]  Macro -> Unload Module : Then delete V_04 in this list

[2.3]  Macro -> List User-Loaded Modules (verify V_04 is gone)

[2.4]  Macro -> Unload Module (verify V_04 is gone)   -  BAD : Shows delete residue in Top Edit box section

In the above cycles - operation steps [1.3] and [2.4] fail.

Once deleted - the file name of the deleted SE module - should be cleared
from the SE state space (as above).

Occasionally - operation step [1.3] seems to work - and the delete residue
is gone.  So for some reason, this failure [x.1.3] - is not always
repeatable. 

------------No Workspace-------

[Y.1,2] = With NO workspace loaded

Perform a load, delete, verify operation - using two different cycles of
operation. 

Load - Delete - verify - verify : Cycle [Y.1]

[1.1]  Macro -> Load Module  (V_04)

[1.2]  Macro -> List User-Loaded Modules : Then delete V_04 in this list

[1.3]  Macro -> Unload Module (verify V_04 is gone)   -  GOOD : No delete residue in Top Edit box section 

[1.4]  Macro -> List User-Loaded Modules (verify V_04 is gone)

Load - Delete - verify - Cycle [Y.2]

[2.1]  Macro -> Load Module  (V_04)

[2.2]  Macro -> Unload Module : Then delete V_04 in this list

[2.3]  Macro -> List User-Loaded Modules (verify V_04 is gone)

[2.4]  Macro -> Unload Module (verify V_04 is gone)   -  GOOD : No delete residue in Top Edit box section   

In the above cycles - operation steps [1.3] and [2.4] pass.

A attached screen shows you can try to delete the 'residue' in [X.1.3,
X.2.4] and you will get a message saying the module does not exist
(because it was already deleted in [X.1.2] and [X.2.2]. 

---------Summary-----------------

Note the bug above - only occurs when a workspace is loaded.

When no workspace is loaded - there is no 'delete residue' in the Unload
Module dialog - top edit box. 

Final note : test case ..V_04..  attached - is just within the current SE
menu size limitation boundary.  One more menu subitem - and the testcase
will have load problems - and other problems as well (this is posted in
another post - on SE V19 RC2 beta testing). 

Just before the menu size limitation is hit (see my other RC2 testing
posts) - SE experiences strange behavior - and eventually has a massive
crash as below.

---------Warning-----------------

Warning : After extensive testing using the test cycles above - the SE GUI
had a massive catestrophic failure - and could not recover - until I wiped
out the configuration directory;

(C:\Users\John\Documents\My SlickEdit Config\19.0.0)

All I did to cause the failure - was the test cycles above - interlaced
with exit and re-entry into the SE application.

After falling back to a previous ZIP version of the above configuration
directory - SE V19 RC2 worked just fine (ie; I destroyed the corrupted
My Slickedit Config directory - and unzipped a previously saved minimal
configuration).

So something in the attached testcase - and the test cycles above - can
bring down the SE application.  I will post this is a different post -
with the stack failures, etc.  I have found that large SE menu modules (as
attached) can bring down the SE application (to be posted in a different
topic soon - with screen shots of SE stack failure messages).