I don't want to make a big deal of this but as a relative newcomer in this forum, while we value your contributions and want you to add to XY via same, you also need to know that some of us have "worked" with Don for years so have some idea of his capabilities, ok? So diss'ng us XY veterans isn't a good way to make friends here.Hiding files and folders in Resources prevents site participants such as students and members from accessing content via the Resources tool.
#Hide folders code#
I began programming in 1975 (maybe before you were born?) and did it as career for 25+ yrs until I retired in 2001.did some in assembly and machine code on both home systems (pre-PC) and large systems, but most was in COBOL.while I don't have much modern language exp (I've done a bit of Perl), you can't say that we don't understand!! As one of my for-fun projects back in the late 1970's, I disassembled and commented the entire TRS-DOS operating sys so that I could make custom improvement patches for it, some of which were distributed worldwide.maybe not relevant to this, but just to show that I'm just NOT a user of PC's. Ok.you have 20+ yrs programming.yea, so you don't think some of us have any? Yes, because while the basic task may be easy to do, the ripple effects on other functions can make it not so.like the list that TheQwerty mentioned. Stretto wrote:You find it offensive that a "vague" claim is easy to implement? If I were you I would apologize for implying that he isn't capable of it. Seeing that Don is pretty active and up to date on his code I have no doubt he can handle it. It is not trying to come up with a new algorithm to solve some new integrodifferential unified field theory. But it is an easy programming task that any third rate programmer can accomplish. cause obviously there are many ways to do it and some are more complex than others. Now, am I saying that it will be easy to implement? Not really. Only arrogance can make you think you have a clue about something you've never worked with. but to claim that it *IS* complex is quite offensive. Obviously when you don't understand something it seems complex. It could simply be a specific text file with the folders in it to something more advanced. This is where any real work will be needed as some type of user interface must be created. A check must be done to know if it is to be shown or not. To hide a folder from *view* one simply has to skip over that item in the enumeration. It usually involves just a few lines of code. This is obvious and any programmer will know this.
Why is it easy? Because When the tree view is displayed it must enumerate over each and every folder to list. How can you know if it is easy or not if you do not have any experience?
I find it offensive that a non-programmer would judge others who make claims about programming. Why is it easy to implement? I've have 20+ years of programming experience from low level hardware and embedded stuff up to newer stuff like. You find it offensive that a "vague" claim is easy to implement? I'm not at all against the idea of hiding items, but I find it offensive when it's claimed that a vague wish would be easy to implement. I should have stated this in my previous post but let me make it clear now: This could be managed with either a new Category within the Configuration or added to List Management.įrom there, Don would have the groundwork to then expand it such that there could be additional paths defined in Admin.ini and the option to not alert the user about these or allow them to be modified. but there would be a "notification" similar to today's VF (# items of #) or another means (new status bar icon?) for the user to identify at a glance that something is hidden - at least as an option. There would be no notification when doing a select all > file op. The items could still be navigated but would be hidden from all (normal/find/branch) views. When populated this would automatically enable Persistent Visual Filters, and filter out those items. One possible solution is for XY to have a Global Inverted Visual Filter which would also be applied to the tree. of items the user typically doesn't use or rarely needs. I think it would be more desirable as a means to clean up the tree/list/etc. Eil wrote:there is no need in any notification -the path is hidden and nothing should give it away.So you view hide folders as a security/privacy measure?
0 kommentar(er)
