avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • July 20, 2018, 07:21 PM
  • Proudly celebrating 13 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - poyan [ switch to compact view ]

Pages: [1] 2next
That would be veeeeeery useful...

"paths and captions"
would be great to also get other options: arguments in command nodes would be important...

LaunchBar Commander / Menu nodes - command functionality
« on: October 10, 2015, 08:25 AM »
In my docks in several instances I need command nodes to start some programs.
Then and when I need some nodes which start the program but use specific parameters. Or which open a file which contains some information related to that program. Or which open a file browser which shows the contents of some folders to which the program is related (reading/writing files, backup directory), i.e. several nodes which are somehow related to the program node.
I have 2 options:
1: one menu node in the dock, the menu contains the program start button and all other related buttons.
This requires always two clicks, whatever I do. Since starting the program is >90% this is a significant waste of time...
2: one command node plus 1 menu node. Which is a significant waste of space...

My suggestion/feature request:
a combined command/menu node: clicking on the icon runs the command, clicking on the down arrow opens the menu.

It might be sensual to adapt the clickable areas. Or to use a short/long-click to distinguish. I would not prefer a combination keyboard/mouse or that purpose.

File Contents Menu Nodes can be built from text files - but only as menu nodes (=sub nodes, at least one level beyond the top level).
Is there any chance to create "top level" command nodes by using external programs, possibly by editing some .ini-files? Will that work, are there some restrictions?
I use quite a lot of command nodes with some minor variances from one node to the next, which is annoying when changing these node by node manually...

Hi, mouser,
I found some systematic behaviour.
Settings: 6 docks, in the LBC tree consecutively named #1 ...#6, all set to reserve space, all with a hotkey, and set to toggle, no position assigned, all other options = default.
dragging #1 to the left: as expected, a grid is shown, then the dock is snapped to the left screen border and displayed covering the whole height of the screen. A maximized window is adjusted, the left border just snapped to the right border of dock #1.
Dragging dock #2 to the left: a grid is shown next to dock#1, and dock #2 is snapped and displayed as desired, just right of dock #1 and covering the screen full height. However, the maximized window is not adjusted, the left border still snapped to dock #1.
Dragging additional docks to the left: they all are snapped to dock #1, resulting in a stack of 5 docks, on top dock #2. Hiding the docks consecutively reveals that the further ones are in a reverse z-order (#6, #5, #4, #3).
After hiding all docks by assigned hotkey, and restored again reversely, starting with #6, the docks are all displayed, and the maximized window is correctly adjusted (left border snapped to the right border of the most right dock, may it be #6 or #1).
Hiding one of the docks left to the most right dock, let us say #4, the docks right to #4 are moved to the left, #3 is now snapped to #5, maximized window is adjusted: still snapped to #1, adjusted width.
If #4 is restored, it is snapped right to #1, yet the maximized window is not restored. Additional docks which are hidden and the restored are snapped right to #1 in stack as described.

Seemes in total that starting with a second dock snapped next to a first dock these additional docks seem to not reserve the space, unless they are restored in reverse order...

Did not test other screen borders (top, right, bottom).

Hope this information is useful. Could also deliver an easy-screencast-recorder file, but it is about 20MB....

Hi, mouser,
Just discovered some further unusual behavior and a possible solution, at least some aspects which might give valuable hints. However, some systematic testing is required and therefore more time than available. I will be back as soon as possible, but not earlier than tomorrow... This is just to inform you that should not invest your time at the moment unnecessarily.
Kind regards

No problem, take your time.

Just to complete: After manually dragging the docks to the "trigger point" the width is as it was set before, they seem to keep their (other) properties.

Another observation: The space is reserved always for the first (most left) dock, but only sometimes for the additional docks, thus programs might be covered partially behind the docks. Could not yet find a systematic situation yet.

Hi, seems to work as you intended.

I suggest to go also the last step: return the results.
If the text has come from the clipboard send the manipulated text back to the clipboard. 
If it has come from the command line, return it by stdout.
If it has come from a file, write the text to a file. Let the user decide whether he would prefer to overwrite the old file, to use a new filename, or to archive the old file and to save the new file with the original filename. Or just offer the first option, but keep the original text for a possible go back.
On demand, open the program gui, but enable a quiet run.

Any idea for using multiple functions on the text?
Just some proposals from a lazy user who tries to reduce the number of unnecessary keystrokes / mouseclicks.

Hi, use LBC docks for starting quite a number of macros, some are of universal interest, some are program specific, as I already mentioned here: http://www.donationc....msg362932#msg362932

At the very left edge of the screen a "basic" dock is positioned, which is visible all the time. Just next to it to the right one of 6 docks shall be positioned which are specific for a certain program. These docks are toggled by hotkeys. All docks are set to reserve space.
Unfortunately, the docks are restored to floating docks, and I have to grab them and drag them to a region just right of the "basic dock" so they find their position and size as desired (attached to basic dock, and full workarea height).
Once I have done this they keep their position and size after toggling.. until restart of LBC.
I tried to reset size and position for every dock, but it did not help.
I tried to set values for x- and y-position - no change.
Do I overlook something?
Or a bug?

Note: there are two more docks (top and bottom), which are set to autohide.

win8.1 64

N.A.N.Y. 2014 / Text Inspection & Manipulation Utility
« on: August 02, 2015, 07:48 AM »
just had the idea that it might be of interest to have some command line parameters.
This would allow to use some predefined sets (started by LBC, or FARR, or a shortcut, or ...) for some text manipulations which occur quite often (in the situation of the specific user, therefore leave it to the user which manipulations are chosen for this predefinition). That would spare
to open the program gui (which may still be an option for approval or additional tasks),
to search and chose the function (maybe scrolling necessary),
to chose/enter a number of parameters,
which could all be done with one click.
It is similar to storing parameters, which was already defined as most needed, but would even be more efficient than that:
I think the most needed feature would currently be storing parameters between sessions and when changing between individual text manipulations.

That was a note to self by the way.

Best regards, Yango

Hi, Mouser,
sorry for the late response, I missed to click notify on response.
#2: sorry, I was inaccurate.
The problem occurs, if I have a shortcut, which is containing a path to program, followed by a path to a file, in order to start the file with a program which is not the standard program.
In this case just the program is started, obviously without passing the file, thus the program uses the file which was the last one opened - as long as "%file%" is in the argument section. If that is deleted the desired file is opened. Since it took me quite a lot of testing - despite I'm not inexperienced - I suggest that LBC handles this situation by itself to prevent users from despair ;-)

Related to that: the "hint" field is filled with program information, not with the filename. And if icons are assigned to the shortcut, they are not used by lbc automatically, either the program icon is used, or it is left blank.

LaunchBar Commander / reserving space with autohide on top
« on: December 11, 2014, 07:05 AM »
this is a request which is just the opposite of

I have a dock on top, set to autohide (btw: what is the difference to autoslide? Could not find any hint in help and see no difference).
When windows are maximized then the title region is quite close to the dock. Therefore quite often the dock is sliding in while I just want to use the title region of the window (minimizing, toggling between max/normal). This requires at least moving the mouse away, waiting for the dock to close, and another try keeping the mouse as far away from the top edge but near enough to be able to reach the title region of the window. In the worst scenario I just clicked at the moment when the dock slides in - and therefore started whatever the dock was setup for...

Thus it would be great to have an option which prevents this unwanted slide-in. I only see the solution to reserve some space at the top of the screen which prevents (maximized) windows from being placed directly at the top screen edge.
As a workaround I use desktop coral whith a height set to 15. But... another program, additional memory use,...

Kind regards

DesktopCoral / Re: Run two instances of desktop coral?
« on: December 11, 2014, 06:14 AM »
I run 3 DesktopCoral instances.
As mouser said: Make directories like "desktopcoral_top", "desktopcoral_bottom", put in each the portable version of dtc.
I also renamed the exe-file desktopcoral.exe in desktopcoral_top.exe, thereby you can recognize these in the taskmanager - and for selective closing by batch.
The only issue is that all instances show the same symbol in the tray, so you have to guess which symbol represents which instance (in case you use transparent mode you can only access dtc via tray symbols). But once set to your needs, it is rare that you would need access...

I have some shortcuts which pass an argument (filepath) to a program.

Shortcuts work fine from the folder, starting the program with the desired file.
Dragging the shortcut to LBC:
1.copy shortcut properties: launch works, however the title and the hints are set to the launched program.
this requires manual correction, since it is not helpful to have many times the same title in LBC ;)
There may be reasons to take the program as title, but it seems to be more logical to take the filename of the argument as title, if the argument represents a file. Or the title of the shortcut.
Maybe a third option in the dialog?

2. link to shortcut:
uses now the name of the shortcut as title, which is good.
when started from lbc the program starts, however with the last file used, not with the file which is the argument...
All paths are without spaces or problematic characters, I tried with and without quotes, the shortcuts placed in the same directory like the files, or in a different one.
Finally, I found the issue: it is the %file%-entry in the arguments section. After deletion the launch with the desired file works.
I suggest to leave the arguments section empty if a shortcut contains a filepath as argument.
Not a big issue, but inconvenient with some dozens of shortcuts.


Hi, mouser,

LBC would have to check if the program file which is to be launched / or the file which shall be opened is accessible and whether the drive is available.
And then offer a user defineable reaction.
If drive is available: file must be moved/deleted > user defined message and/or command: search in alternative path (a backup?) or launch specified program (like search), passing the filename as search parameter;
if drive is not available: submit user-defined message and/or launch user-defined command: launch truecrypt + arguments or attach external drive; meanwhile LBC waits for the availability of that drive... for a certain time...


LaunchBar Commander / Re: Program Specific Launch Bar
« on: August 27, 2014, 03:27 PM »
I meanwhile implemented it for me using an external scripting program which shows one or two of a bunch of LBC docks while it hides the other ones, depending on the program which is activated. This required the definition of the size and the position of the program window and also the LBC window(s).
This script is initiated every 2 seconds which is a good compromise between a little delay in activating the LBC dock and the activity of the scripting program.

From my experience, if you still plan to implement it in LBC (which I would prefer/suggest):
allow more than one dock per program (there are always some commands which are "universal" or at least usable for more than one program, thus I have a dock "basic" which is displayed additionally to program specific docks)
allow the docking to any desired position (not only on top of the main window, but also to the left/right/bottom; and whether dock is to be centered; in relation to a single main window or also in relation to a group of main windows)

Since I had to define the window positions anyway I extended this to position two or more program windows plus some LBC docks. This was just a "natural consequence" so you might consider that this will definitely be a feature request.

I have the same question.
Is this implemented meanwhile? If yes: HowTo?  (could not find it in help).
If no: Could it be done? Would be great!

LaunchBar Commander / Relative paths in arguments
« on: February 25, 2014, 12:37 AM »
I use LBC portable from a stick.
Starting programs with %APPDRIVE% from that stick works fine.
However, passing arguments isn't possible using %APPDRIVE%.
I finally remembered the conventions for relativ paths using .\subpath - it is working now!
Since this knowledge is not so common, and I lost quite some time trying to use %APPDRIVE%,
I suggest to help users with this topic by adding some sentences to the help and
show some hints ("argument not valid, ..."), instead of just starting the program without the argument/with an invalid argument,
or (better) by accepting and "translating" the environmental variables also in the arguments.

LaunchBar Commander / Re: System functions not being correctly copied
« on: November 10, 2013, 12:16 AM »
On my win8.1 surface the parameters are copied,
however the icons are not copied.

LaunchBar Commander / Program Specific Launch Bar
« on: November 05, 2013, 10:22 AM »

I proposed this feature already here

Now, with the sendkeys feature I try again, since it is imho a logical idea:

The idea of sendkeys is to control a program by another one. If several sendkey actions are combined this enables to do complex actions with just one command. This reduces the number of keystrokes or mouse actions. Thus, even in case a program does not contain a macro-functionality by itself, sendkeys implements this, and that is fine.

The question is how to start such a sendkey-macro.
The number of hotkeys is limited, and even if not - how many can a normal person remember?
Therefore, programs like LBC exist, offering icons for starting programs.
But the number of icons is also restricted, and furthermore, if lots of icons are displayed, it may be difficult to identify the correct one.
Therefore, docklets and submenus can be implemented. But this requires at least one additional click to start the macro. And in case of macros which control more than one program, you have to remember in which submenu the icon is located. And, if you use a large monitor, the ways for the mouse may be quite long.

I propose to implement:
launch bars which are specific for a certain program.
If that program gets focus, this specific launchbar is started or placed on top.
To reduce the long ways for the mouse, this specific launchbar is docked to the program window.

1. I nearly was successful with a workaround:
I found here on donation coder WinWarden.
This program allows to place a window (like a launch bar) relative to another one.
Unfortunately the LBC-windows refuse to be resized by this program (and by other programs as well).

2. Also here on donation coder I found barnacle, which injects individual taskbars into other programs`  windows. But only on the top side, and it does not work with all programs.

WOuld be great if my proposal could be considered,
either by implementing it in LBC directly,
or if you could make LBC windows resizable..

Thank you

I use truecrypt for some important data, and I like to open it only if it is needed.
Thus if I run programs which need the truecrypt-"drive" open I get some error messages, have to close these message boxes, call truecrypt, and restart the  program.
Same with some file manager programs which show error messages if drive not available.
Same with browsers if connection to inet not available.

All that could of course be done with batch files, scripting programs,
but I could imagine that many users are not familiar with the pertinent batch commands,
and a simple functionality to check availability of drive/program started/Inet connection and to react ´(start of program before launching the final program) could increase the value of LBC...

Sure, the risk is that this might encourage much more complicated demands. Like start of some programs at the same time and a defined positioning on the screen...

Just an idea; I myself use some scripts, but that means at least additional files...

Kind regrads

could not find much on this, except that you can add new menues by some plugin/textfile.

However, it would be great if the icons of an existing entry could be changed according to some action or to a returned value of some external program.
For example: changing from a red colored icon to a green one if program is running, or, if an external/network drive is available or ... whatever. Should be more than just two options...
One may even think on displaying continously changing data.
I know there are a lot of programs for displaying everything of interest and even beyond that ;-)  (used samurize some years ago), but at the moment I'm stuck to LBC and it would be great to not have the necessity to install and configure another program which will interfere with LBC, at least will reduce the working area by applying another bar to the monitor.
A compromise could be that LBC allows an individually definable part of the space it is using from one end of the monitor to the other when docked...
Any idea in these directions?


In my environment (win XP Prof, LBC 1.124.01) the title of the lbc window is the dock node name....


LaunchBar Commander / Launchbars docked to specific windows
« on: April 14, 2011, 07:49 PM »
I don´t know whether this is the right section, however, LBC might be a basis...

I already proposed to have some docks which are specific for certain programs.
I use a lot of little helpers, mostly self written scripts, to enhance the functionality of quite a number of programs which do not offer hotkeys for menu items which I need quite often, or some formatting needs 4 mouseklicks...
At the moment I use some docks (see above link for further information) which I change according to the actual window - by striking a hotkey, and the docks are located at the side of the screen. Thus, it is a long way for the mouse to travel to the dock and then back again, at least on a monitor of a certain size....

What I´m thinking of: placing buttons in the title line of a window - of course specific for that window. If the window is activated or launched, also the extra-buttons are accessible, if the window is closed or minimized, also the buttons disappear. If the window is moved around, the buttons will move as well...  It is like a programmable command bar for every program, even if the program is not offering this feature by itself.

Thus, one would have a dock somewhere on the side, or as a popup menu, for general purposes (launching the programs, ...) and additionally program-specific docks (unlimited in number) located in the title line, or at the left or right border, whereever they do not disturb.


LaunchBar Commander / Re: Icon display: mean quality
« on: March 23, 2011, 03:33 AM »
Hi, mouser,
thank you for your fast reply. The launchbar is included in my first posting. Look at the left three icons (firefox, thunderbird, freecommander) and the one at the right (ccleaner) - they all have this lucid "shadow" or borderline. These icons come directly from the exe-files.
The forth icon is one that I made using icoFx (.ico-file) with round and oblique outline structures - no "shadow".
And number 5 & 6 also are from the exe-files, but have only vertical and horizontal outlines - also no shadow.
It is only evident if you use dark colours or you set to "translucent", and your desktop is dark. You can a little see it with your darker skins, but mostly the skins have a colour very similar to that "shadow" - so you don´t see it at all. I guess it is a problem in "interpreting" the icon-format used in the exe-files.

Or do you mean something else?

Kind regards

for me the 2 offered icon sizes are not convenient - the small ones are too small, not good to recognize, the big ones are too big - in between would be great. No way for the user to set that value individually?


Pages: [1] 2next