getting public property from subform

thanks Christian!! i thought i posted a reply on this question but i guess i forgot to hit send.

as always, your advice worked perfectly = )

whilst reading the last paragraph of your comment here, i thought about my app and its structure - and also the comments made on it previously by everyone.

i think that how i structured my app is not wrong - in the sense when i'm adding features now and extending it, i can do it. can i do it easily? hrmm, i CAN do it but it is a little bit tedious - i put a lot of "red tape" / "seemingly unnecessary code" in my app so that the groundwork for extending it is there and it can be extended definitely - whether extension is easy or tedious - at least it is following strict explicit rules and so long as i follow those rules i can extend me app = )

HOWEVER, as my skill level increased during the development of the app due to your fantastic coaching and all the advice from the other fantastic experts here as well and all the reading i've done, i've changed the "code rules" a little bit in my app and i have not had the time to update it yet. i doubt i can in quite awhile.

but to critique my app now,

1) i need to streamline my code getting rid of things that i thought i would need last time but i don't anymore
2) i need to follow a more human understandable framework (more on this below)

i went to re-read your answers to my question "how to pass dictionary through openargs" https://www.experts-exchange.com/questions/28228242/how-to-pass-dictionary-through-openargs.html?anchorAnswerId=39472548#a39472548

Hi,

no, it's like in nature: The child should not control the parent, the parent should control what the children has to do.

So not the child should find out the parent, the parent should fill a "Parent" property (should not be named "Parent" as that is already in the properties of controls/forms) in the child object so that this can access the parent in a generic way without knowing which parent has opened it (that differs a little bit from nature...;-)  ).

Exactly that's what an Interface can do for you: If you implement some standard properties which you can use in such cases you can be sure that all needed elements are available in the object which implements this Interface. One could be something like "MyParent".

You can't simulate what acDialog does, this parameter can only work in this single scenario: If you directly use it within OpenForm. If you would, for example, open the form first in hidden mode and then try again OpenForm with acDialog to make it visible the acDialog does not have any effect.

So the better way is to design the parent form in a way that it simply does not need the acDialog. Like in the demo above: The parent form opens the child and then it doesn't wait to come back, it will be inactive until the child form fills the property of the parent form which then can go on working with the returned result. The result for the user is the same if you switch the modal property of the child form to True: Any other form cannot be used anymore until the child form will be closed.
If the child form is closed and have returned the value to the parent form this can go on working with it - and as the child was informed before who IS the direct parent it will report to this one only with no need to search through any collection and of course not by name which is very unsecure as you have seen in the demo above where any child form has the same name. Without using a parent reference the child form could not be found if the child form would open another child form and this one would need to find out now which of the ten opened forms is the the right one - but if the grandchild has also got a reference to the right child form it's no problem to directly report to exactly this one and so the acDialog is never needed.

Cheers,

Christian

when i say more human understandable framework, i mean something like what you're teaching me above. like how things happen in nature.

hrmm you know i read somewhere before on this observation that the world is very human customised. in the sense railing on a staircase going down. why are they metal or wood, instead of say a gooey material (sorry i'm not very familiar with materials engineering!! haha = ))    )? because the human skin is more compatible with metal or wood (or others). why are shoes made from a certain material as well? because our human programmed body is most comfortable towards that material.

this question comes about when we're deciding cryogenics. if we're going to make artificial bodies, why do we choose silicon? (err i think they're choosing silicon i'm not sure!! haha) because it's the closest to our human bodies? so what if we decide that everyone's brain were to be transferred to a metal body with high electrical conductivity? the landscape of our world would definitely change - and pronto haha = )

so i think as a human, i have to understand my limitations. i also remember reading somewhere in an established religious text (the religion is based on logic not faith) there are deliberately unanswered questions because these exceed our human limitations and we're just not programmed to understand these things. a human can only be a good human, best human, enlightened human, wise human but at the end of the day the human is still a human. some knowledge belongs to wisdom only attainable by using a different processing architecture - NOT the human brain.

and as such, i need to structure my app more towards where you're pointing - analogies of nature (mostly) or things that we already understand - and thus object oriented programming. using our pervasive knowledge and experience of tactile objects in the physical world to model our intellectual understanding of programming = )

at present, these are the 2 criticisms i can give of my own work! i'm sure there are more but i need to clear these 2 first before i can move on to more criticisms = ))

thanks for all your help and guidance Christian!! = ))

thanks gustav!! yup i wrote .Form in my code but i guess i wasn't thinking straight when i wrote subform in the aircode above!! haha = PP

but thanks for pointing it out!! = ))

Hi,

although getting a little bit philosophical now, the thought of doing it like nature does is not so wrong - but indeed I did not thought in this direction when I wrote this, I only meant that as a comparison in this single scenario.

What we can learn from nature is that in nature the things are designed in a way that anything has a sense, there is nothing which is not needed although we humans does not understand the sense of anything which is there. We look at a flower and see a colorful, nice plant, we enjoy it and like the smell. But the nature didn't design a flower for the purpose of being enjoyed by humans. The flower wants to survive and reproduce and so it must get help by other creatures and so it is perfectly designed for the eyes and the body of a flying insect to carry the pollen from one to another flower of the same type. The color has a UV component we humans even cannot see, but the insect can.

So yes, we can learn from nature to avoid doing things which are not necessary and concentrate on pure functionality where we also can add: Less is more. If you can do the same functionality with less expense and maybe better performance then it is what the nature would also do.
But let's think a little bit more about that: You can reach a goal by writing one codeline. If you must do it 20 times you can reach it by writing 20 times one codeline. That would be effective and maybe even more performant than writing a more complex sub which could do the same - but the sub would need to add overhead which will also be executed 20 times: You need to fill in some parameters, the parameters will be read by the sub, it will be tested if it is OK, an error handler will be added to catch errors which may occur, and if the sub is a function it must fill in a return parameter and the calling procedure must read that out, maybe also test it's value and react on that - this code would cost a lot more and will be less performant than writing the same codeline 20 times in the procedure. So what would be the way the nature would do in this case? Is it repeating the same 20 times or will it be grouping the functionality so it can do more with the result although it maybe costs more?
Look at this picture:
Romanesco

I wouldn't say that the nature has developed this fantastic geometry by simply repeating the same "codeline" thousand times, I would say it is based on one algorithm which produces different similar looking outputs. So the nature does the same as we do: It looks how it can achieve something with less expense, and although writing the same code 20 times would be more performant and less to think about it would cost more energy in the end to write the same code 20 times than writing a sub once and reuse it every time - otherwise the next Romanesco would need to invent the wheel again for any structure (and I'm sure that would not look as equal as the current result does). So it uses the things which got approved and tested during evolution. Try and error. We do similar things in development.

Cheers,

Christian