hahaha. It will take you 1 or 2 weeks to get a decent grasp of VMP - but well worth it. On many of the VMP based VFP apps I created I used this 3-levels of code logic myself. The VMP (base classes), then I had a 'middle level' of classes I made that I would use between a bunch of VFP projects (had some more stuff in it and some goodies I wanted in all my apps), then I would subclass that level for each specific app I made. I suspect that there are quite a few others that did the same thing. Any chance you can tell us what the app does? Sounds like it could be one of my old ones....


>Sorry. The app that I got is a mess, and I as I started lookin at this code, it all seems
>very confusing. I got the impression (incorrectly is seems) that it was just thrown
>together, rather than carefully planned out. I obviously need to spend more time studying
>it.
>
>One problem is that it appears that the VMP base of code I have has been subclassed, then
>that level was subclassed again, and there are changes to all 3 levels of the code,
>including VMP, which of course would make any app difficuly to comprehend.
>
>No disrepect intended.
>
>
>
>
>>>Anyone using Visual MaxFrame?
>>
>>Not only do I use it, I have helped develop parts of it in the past. I must say you're not going to get a lot of willing help by starting off taking shots at it.
>>
>>>
>>>I just inherited a legacy app based on VMP. I don't know what version of VMP this is.
>>>
>>>From what I can see, VMP isn't all that great. There are alot of PRG's (Why not in
>>>class libraries??)
>>
>>Simply because the fastest and most flexible way to have UDFs is for them to be separate. Calling methods of one or more classes is slower than calling single UDFs in separate PRGs. Having multiple UDFs in a single PRG also prevents multiple developers working on those UDFs at the same time.
>>
>>>and there seems to be alot of duplicated code.
>>
>>Such as?
>>
>>>
>>>Add to that the file names are rediculous, ie, 'x1fml.prg', 'x8setcls.prg', 'xxiudlog.prg',
>>>and so on. These names are entirely meaningless and don't help me learn the framework at
>>>all.
>>
>>This I will agree with. There was a time when certain operating systems did not deal kindly with long file names. This is a hold over from then. Drew normally named methods in a very verbose manner.
>>
>>>
>>>There seems to be no central coding style.
>>
>>The style has evolved over the time. There was no reason to go back and retrofit working stuff to meet a current style. That would be expensive and introduce bugs.
>>
>>>
>>>And there are really strange functions that don't seem necessary. I'm scratching my head
>>>wondering, "Why would someone do this???"
>>
>>Such as?
>>
>>>
>>>And, in all of the visual classes there is method for comments called 'zreadme'. Instead of
>>>actually commenting out all the text in here, it's all wrapped in #IF/#ENDIF statements. Now
>>>I'm sure someone thought this was cool to do, but it make searching with the Code References
>>>dialog that mich more difficult because since it's not actually commented out, the 'Ignore
>>>Comments' option doesn't apply, causing the search results to be overblown with references
>>>to items that are not real code lines.
>>
>>The reason for that was
>>
>>There is a built in search utility that makes the code references thing look weak. xxdtsearch is far more capable.
>>
>>
>>
>>>
>>>I can see I have a lot of work ahead of me.
>>
>>Unfortunately, many people have gone off in different directions in their implementations of VMP systems. If you've inherited a n-tier system you'll be better off to completely ignore the non-ntier stuff and vice versa.