I truely love it when the gods dump something on my desk and say either do it or fix it. You have no knowledge of the app, language and do not have the tools to do the job. But you are expected to deliver on time and under budget.

Did anyone in management ever consider including the "chosen developer" at meetings to discuss what new and exciting project is about to blossom? How about some support from management? The impossible dream! :)

How about a new category for the UT. Call it Management and let us at the gods!

P.S. Please note the lower case g in gods. This indicates a lessor deity. :)


>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.