>>>>>There's a time and place for everything. Moving all code under every circumstance out of a button's click() event, and only ever calling method code, is going to an inappropriate extreme in my opinion. It's like using "m." prefixes on everything. It clutters up the code to such an extent that I would advise against using it. In my 32+ years of using Fox-base software, I've only ever had one name collisions where I could've benefited from using m., and it was a fluke thing that would've been corrected with properly named fields and variables anyway.
>>>>
>>>>More bad advice. Using m. consistently means your code doesn't depend on a naming convention (and incidentally, runs faster). Using it only sometimes means the next person to read your code has to try to figure out why you did it that way sometimes and why you didn't at other times.
>>>>
>>>>I try to write code that the next person who has to work with it can understand without having to get into my brain (and, for that matter, that I can come back to years later and understand without a huge effort). Standards help. Doing things the way the language was designed helps.
>>>>
>>>>Maybe you're the only one who works on your code and you don't inherit code from others. I've made a career of taking over other people's code and expect that I'm leaving code behind when I retire. So I've seen really good code and really bad code, and I'm trying to ensure that what I leave is really good code.
>>>>
>>>>Tamar
>>>
>>>Using m. is really important, especially when dealing with inherited projects and third party tools. Just today I had a situation where I used Marcos nfJsonRead() function and it crashed under certain cases. After at least one hour of debugging and trials it turns out this legacy app has a table called OBJ, and nfJsonRead has an object variable called obj which is sometimes referenced with and sometimes without m.
>>>
>>>I was lucky that I did get the error in develop, because the OBJ table is not always open. Therefore this error could have easily been distributed to end clients, with errormessages that would be really difficult to trace. In that case I would estimate that the time lost would have been close to one working day.
>>>
>>>Now I would never have called a table OBJ, neither a variable, but when dealing with projects of other people you can never be sure what you may encounter.
>>
>>Hi Christian, sorry to hear that. I was pretty sure I used m. everywhere it was needed , so can you please point me out if you are using the last version, and if that is the case, wich line gave you trouble ? here is the actual nfJsonRead() function:
>>
>>https://raw.githubusercontent.com/VFPX/nfJson/master/nfJson/nfjsonread.PRG
>
>Hi Marco,
>
>This was a situation definitely difficult to foresee. But it does show the meaning of the m. and how important it can be even in places where you would not expect it.
>
>

>CREATE CURSOR obj (Field1 C(10))
>
>obj = CREATEOBJECT("Empty")
>ADDPROPERTY(obj, "Test", Createobject('empty'))
>
>vari = "Test"
>Messagebox(obj.&vari) && Exception Variable 'Test' not found.
>Messagebox(m.obj.&vari) && Works.
>USE IN Obj
>Messagebox(obj.&vari) && Works.
>

>
>If adding the array property it will not give the error:
>Messagebox(obj.&vari(1)) && Works always.
>
>>
>>Thanks!

If nfJson has a bug, can you tell me wich line you had to fix and how to reproduce it?

PS:
Ok, I found the missing "m." in line 363. ;-)

Please don't hesitate in sending issues through github project site.

Thanks!