Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Ilya Rabyy
  Where is Ilya Rabyy?
 Fountain Valley
 California - United States
 Ilya Rabyy
 To: David Hall
  Where is David Hall?
 Birmingham
 United Kingdom
 David Hall
 Tags
Subject: RE: libraries in applications
Thread ID: 188928 Message ID: 188987 # Views: 1 # Ratings: 0
Version: Visual FoxPro 7 Category: General VFP Topics
Date: Tuesday, August 12, 2008 9:49:39 PM         
   


> > If it was a good design, and if every one (or at least majority) of the subs (procs and functions) are made as much generic as humanly possible, that would/should had made all the subs in those .APP modules, as well as modules themselves, independent from one another. (In part - if there are no implicit memvars declarations, with consecutive use of those memvars in the called subs.)
> >
>
> Ilya,
> as far as I can see, every local variable (memvar) is declared local, and the procs are very generalised - but that very generality is what causes the 'mainlib' containing the general procedures to be incorporated in every .app.
>
> Perhaps it would be better to explain in more detail the procedure which needs to be changed. In the case in point, it is a proc called IncriTlast, with LPARAMETER lcField.
>
> lcField refers to one of the fields in a table, and the various fields are used in one or another place in the whole collection of .apps. Here is some of the code
>
PROCEDURE IncriTlast
> LPARAMETER lcField
> LOCAL lnSelected,lcUniqueID,llWasShut
> 
> lnSelected = SELECT(0)
> IF USED("TLAST")
> 	llWasShut=.F.
> 	SELECT TLAST
> ELSE
> 	llWasShut=.T.
> 	=UseTomTable("TLAST")
> ENDIF
> *    get next document numbers from TLAST
> DO WHILE NOT FLOCK()
>     WAIT WINDOW NOWAIT "TLAST is locked by another"
> ENDDO
> 
> DO CASE
> CASE lcField = "LIN"
>     *    order line numbers are right justified
>     lcUniqueID = STR(VAL(Tl_LineID) + 1,8)
>     REPLACE Tl_LineID WITH lcUniqueID
> CASE lcField = "CUS"
>     *    customer numbers are left justified
>     lcUniqueID = TRANSFORM(VAL(Tl_Custno) + 1)
>     REPLACE Tl_Custno WITH lcUniqueID
> 	
> ...etc, etc
> 
> OTHERWISE
>     =MESSAGEBOX("unknown call "+lcField+" in incriTlast",64,"System Error")
> ENDCASE
> UNLOCK
> IF llWasShut
> 	USE
> ENDIF
> SELECT (lnSelected)
> RETURN lcUniqueID

> Now, since this highly generalised code is in mainlib, and mainlib is included in
> all .apps, if I change just one of the formulations of lcUniqueID, is it the one
> in the top level .app that needs to be re-compiled, the .app in which that
> particular formulation is used, both .apps, or all .apps?

My apologies in advance, kind sir, for my possible misuse of the words, or inappropriate verbiage: English is still my second language (for the measly last 16 years, and Russian being the first), and I mean no offense whatsoever. With this said:
I take it this whole app is not your own opus, is it?
With all due respect, colleague David, I disagree that this function is as generic as it could have had been made, here's why:

1. Tables and fields names are hardcoded;
2. The calculation of the next UID varies upon the hardcoded fields' names, in the DO CASE/CASE/ENDCASE construct.

(That is not to mention that the naming conventions in VFP are not entirely followed by: "LPARAMETER lcField" should be "LPARAMETER tcField".)
To be 100% generic, this function's signature should be something like

FUNCTION IncriTlast(tcTableAlias, tcField, tcTLastFld)

That last parameter is to eliminate the need for the CASE construct.

However, this not-quite-generic-ness may be beneficial in your case: you may add another CASE statement in your DO CASE construct without any harm (I think).

Now, if "mainlib is included" means literally included (or rather imbedded) into the code of a module - you will have to re-compile all the modules containing this function.

If, on the other hand (and I hope this is exactly the case), this MainLib is a separate PRG, and "included" means that any other module in the program refers to is like

SET PROCEDURE TO "MainLib.PRG" ADDITIVE

(which, in my humble opinion, would be the proper design manner), the only module you would have to re-compile is this MainLib.PRG.

Have I answered you question, colleague?
Regards,

Ilya

ENTIRE THREAD

libraries in applications Posted by David Hall @ 8/12/2008 4:56:11 PM
RE: libraries in applications Posted by Ilya Rabyy @ 8/12/2008 5:19:41 PM
RE: libraries in applications Posted by David Hall @ 8/12/2008 8:47:21 PM
RE: libraries in applications Posted by Ilya Rabyy @ 8/12/2008 9:49:39 PM
RE: libraries in applications Posted by David Hall @ 8/13/2008 11:44:54 AM
RE: libraries in applications Posted by Mike Yearwood @ 8/13/2008 4:03:49 PM
RE: libraries in applications Posted by Ilya Rabyy @ 8/13/2008 5:22:57 PM
RE: libraries in applications Posted by David Hall @ 8/13/2008 6:17:10 PM
RE: libraries in applications Posted by Ilya Rabyy @ 8/14/2008 4:43:49 PM
RE: libraries in applications Posted by David Hall @ 8/14/2008 6:17:06 PM
RE: libraries in applications Posted by Ilya Rabyy @ 8/14/2008 6:22:07 PM
RE: libraries in applications Posted by Mike Yearwood @ 8/13/2008 4:24:31 AM
RE: libraries in applications Posted by David Hall @ 8/13/2008 11:59:28 AM
RE: libraries in applications Posted by Mike Yearwood @ 8/13/2008 4:00:00 PM
RE: libraries in applications Posted by tushar @ 8/13/2008 5:22:28 AM
RE: libraries in applications Posted by David Hall @ 8/13/2008 11:56:10 AM
RE: libraries in applications Posted by Tom Saddul @ 8/13/2008 12:52:40 PM
RE: libraries in applications Posted by Ilya Rabyy @ 8/13/2008 4:37:57 PM
RE: libraries in applications Posted by tushar @ 8/13/2008 2:59:19 PM