Removing "Add document" and "Add folder" buttons.

Hi. I want to remove the buttons that appared in Livelink 9.2 beside "Add Item" menu. There are two buttons "Add document" and "Add folder", but I don't need them in my interface, because they make things complicated and are not needed. I need only "Add Item" menu and nothing more.I have Builder in my command and I can modify some OLL or Weblingo files. Maybe I don't need to hack and can make it easyer, but I don't have any ideas.Thanks ahead!Taavi

Find more posts tagged with

Comments

Taavi_Ilves

The solution is simple, if you have a builder at hand.Just explore to "WEBDOC" ospace (make sure you have Ospace, not Inheritance view), open "DocNode" object. There are 2 subobjects "Folder" and "Document", which both have fDisplayIcon feature. When you want to disable those "Add Folder/Document" buttons, just unlock the "WEBDOC" ospace and set fDisplayIcon features under those two objects from True to False. Save and export and restart LL server.For me, it did the trick. Very big thanks to Keit from Microlink Estonia.Taavi

Howard_Pell

Message from Howard Pell <hlpell@opentext.com> via eLink

Very good, but may I remind everyone that unlocking Livelink OSpaces and modifying them in any way is not supported.

The supported way to do this is to orphan the Folder and Document objects in your own OSpace and make the changes there.

Howard

Howard Pell
Senior Technical Educator
Liaison, Special Projects
Open Text Corporation
www.opentext.com
(519) 888-7111 Ext. 2203

Education is for improving the lives of others and for leaving your community and world better than you found it.
- Marian Wright Edelman

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

I agree with Howard, that you shouldn't change the core Livelink OSpaces. That would not result in a maintainable solution.

I'm also not in favour of the solution Howard suggests. The problem with that solution is that if for another reason you have to change things in one of these objects and you apply the same method, then only one of the two will be applied.

I would create a patch. Either as a separate patch file or as part of a module.

Hans

Howard_Pell

Message from Howard Pell <hlpell@opentext.com> via eLink

Perhaps someone in Support can respond, but I was under the impression that Support would prefer if our customers did not create their own patches.

Donna Nalls

Hans,As you well know, there are many ways to approach any Livelink customization - I believe Howard's point was to say that unlocking a core OSpace is unsupported and may cause serious problems with the livelink system.I have been doing Livelink development for 8 years and still have problems when i try to write a patch....i would prefer Howard's suggestion over writing a patch file...which also have their issues.Another possibility would be to make an object reference to these two objects in your custom ospace by dragging the objects from one OSpace Browser window into your Root object...then in your Root.Startup, you can reference the features that you want through your object reference.i.e. - drag the "Folder" and "Document" objects into the method list of your custom module's Root object. Name them WebDoc_Folder and WebDoc_Document, respectively.In Root.Startup....add the following:.WebDoc_Folder.fDisplayIcon = FALSE.WebDoc_Document.DisplayIcon = FALSE-- this sounds complicated the first time you do it, but, really, it's quite simple and i use this method all the time!We all have our preferences...but the one preference should NEVER be to open a core livelink ospace.Best,Donna NallsWisteria IT

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

Donna,

As I wrote in my response to Howard, I agree with him that you should not change core Livelink OSpaces.

The method you describe is indeed one of the ways to patch something from inside your own module. The way I would do it in this case is by

orphaning WebDoc_Folder to my OSpace and name it Patched Folder. So it will be clear that some patching is happening.

The __Init function of Patched Folder I will change to

.OSParent.fDisplayIcon = FALSE

Hans

Alex_Kowalenko_(x-eu0016039_-_(deleted))

Message from Alex Kowalenko via eLinkYes, there are several ways to approach Livelink customizations. The art ofthis craft is to choose ways that are least intrusive and most supportable.Yes, and elegant too.I have seen many customer Livelink systems running with in-line changes toboth OSpaces and WebLingo files. These may seem like quick, cheap fixes. Butin the long run they are neither maintainable nor cheap. No responsiblecorporation should ever tolerate this type of development. While in-linehacks may suffice for proofs-of-concept, they must be changed in theproduction design.What Donna is suggesting is an example of a technique that I call therun-time over-ride. There are many variants of this technique in practice.It is very effective when there are no call-backs, hooks or crooks to behad. The HTML map (part of the CustomizationsRT module) is an example ofthis technique.I find that a very useful adjunct is to maintain a list of over-rides andcompare them to core code upon start-up. This can flag differences anddirect the developer to update certain custom code in case of Livelink ormodule upgrades. In large systems this can save much time and cost for theupgrade effort.By the way the second of Donna's over-rides should be ....WebDoc_Document.fDisplayIcon = FALSE... otherwise the DisplayIcon script is over-ridden with a Boolean featureresulting in an SDNR error.-alex------Original Message-----From: eLink Discussion: Development Discussion[mailto:development@elinkkc.opentext.com] Sent: Thursday, June 16, 2005 12:18 PMTo: eLink RecipientSubject: Hans,Hans,Posted by Nalls, Donna on 06/16/2005 12:14 PMHans,As you well know, there are many ways to approach any Livelink customization- I believe Howard's point was to say that unlocking a core OSpace isunsupported and may cause serious problems with the livelink system.I have been doing Livelink development for 8 years and still have problemswhen i try to write a patch....i would prefer Howard's suggestion overwriting a patch file...which also have their issues.Another possibility would be to make an object reference to these twoobjects in your custom ospace by dragging the objects from one OSpaceBrowser window into your Root object...then in your Root.Startup, you canreference the features that you want through your object reference.i.e. - drag the "Folder" and "Document" objects into the method list of yourcustom module's Root object. Name them WebDoc_Folder and WebDoc_Document,respectively.In Root.Startup....add the following:.WebDoc_Folder.fDisplayIcon = FALSE.WebDoc_Document.DisplayIcon = FALSE-- this sounds complicated the first time you do it, but, really, it's quitesimple and i use this method all the time!We all have our preferences...but the one preference should NEVER be to opena core livelink ospace.Best,Donna NallsWisteria IT[To reply to this thread, use your normal E-mail reply function.]============================================================Topic: Removing "Add document" and "Add folder" buttons.https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=4010634&objAction=viewDiscussion: Development Discussionhttps://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=786303&objAction=viewLivelink Server:https://knowledge.opentext.com/knowledge/livelink.exe

Donna Nalls

Sorry Alex, I made a type-o...as i'm sure anyone reading the thread would have realized......but, truly, how fortunate i am to have you and Hans available to point out all of my failings! And, how fortunate you both are for this wonderful forum where you can pontificate until your hearts' content.It truly makes the rest of us mere mortals apprehensive to join in these discussions at all!I think this deputy is just gonna have to turn in her badge!Best,Donna

Alex_Kowalenko_(x-eu0016039_-_(deleted))

Sorry, the type-o was not my point. Was I really pontificating?I really must get back to work.Please keep the badge. You earned it.-alex-

Howard_Pell

Message from Howard Pell <hlpell@opentext.com> via eLink

After testing both my method and Donna's method, I would suggest that Donna's method is the way to go. It is easier to implement and avoids a side effect that mine does not.

The side effect is that LL is now looking in my new module's support folder for icons to use on the "Open" (formerly Browse) pages. It is easy to fix but why do it when Donna's method needs no fixing?

Thanks Donna.

Gerald_Bulmash

Very cool method, Donna.I thought I was slick when I thought of a very similar way of doing the same exact thing, but yours is a little bit more streamed lined. In my example, I would just hard code the reference id into my startup script, but the drag and drop is much easier!GregR

Donna Nalls

hey greg'ry -- sooo nice to know you are still out there!!! i can not take credit for this little trick, as it was taught to me many years ago by the incomparable Martin Scott!!! However, i was a good grasshopper and kept his little trick close at hand and use it frequently!!! I was darn lucky to have martin as one of my mentors when i came to Open Text!!i think the problem with hard-coding the reference id is that when you install the module in a new environment (with potentially different modules), it is likely that reference ids can change (not sure, but i think that's true).i hope all is well with you!!!Donnadnalls@wisteria-it.com(now that they have applied privacy policy - it's hard to get each other's contact info, so now you have mine)...keep in touch!!!

Taavi_Ilves

Hi!Thanks for all replys, I knew this hack is dirty, but had no other ideas at the time.If I want to create my own module that would run every time LL server restarts and set those default settings from TRUE to FALSE, what should I do?And thanks ahead.