XYplorer Beta Club

Without putting myself across in a negative way, can you please use the "Edit" button instead of double-posting? Every little bit counts in the efforts of keeping the forums clean and tidy

Stefan wrote:

admin wrote: 1) maybe <curpath_i> (inactive); but that would be useful for all <cur...> variables. Maybe there's a smarter way to do this than add a full second set of variables. Hmmm...

maybe we can write smtg like <<curpath>>; <<curitem>>
or <icurpath>; <icuritem>

if we want to access the inactive panel

and your code can recognized this alternations?
IF start with two <<
IF starts with 'i'

Not convinced of the suggestions but I see the use of the idea. Meditating...

zer0 wrote: can you please use the "Edit" button instead of double-posting?

[Sorry] i have to say NO.
I have to write my thought down before i forget them (because doing other things in between)...
and with EDIT the last modifications may not be recognized by the auditorium.

Stefan wrote:

zer0 wrote: can you please use the "Edit" button instead of double-posting?

[Sorry] i have to say NO.
I have to write my thought down before i forget them (because doing other things in between)...
and with EDIT the last modifications may not be recognized by the auditorium.

Correct.

Nah, I hate to say this, but both of you are slightly incorrect. There are ways to highlight the edits in ways that would catch the eye. J_C_Hallgren manages to do it and so do I. Besides, this is a forum to have an intelligent discussion, not Twitter But hey, admin approves, so I guess it's cool.

Regarding the XY-vars for inactive panes, I think we should take a broader approach, as the differences between the XY-vars and GetInfo can be a bit annoying.

To not break backwards compatibility I suggest the following:

1. Deprecate (but don't remove) GetInfo.
2. Create a new command GetControlInfo(). (Described below).
3. Create a new XY-var <GCI [Args]>, which acts as a call to GetControlInfo in non-scripting areas.

<GCI [Args]> will be an XY-var which calls the scripting command GetControlInfo() with the same parameters and is replaced by the returned result. This can be used in places where you don't generally or cannot use scripting. If any of the arguments contains a ">" it will obviously need to be quoted.

<GCI Control, Info[, Params]>
GetControlInfo(Control, Info[, Params]);
Briefly:

• Control is the control that we want information from.
• Info is the type of info to retrieve and depends on the value of Control.
• Params is any additional parameters required by Info.

Valid Control Values:

• L = Active List Pane
• I = Inactive Pane
• 1, 2 = Pane by Number
• A = Address Bar
• T = Tree
• C = Catalog
• B = Toolbar
• X = Other/Global/XY

Valid Info, Param Values:

• CountItems, None
  • Number of items.
  • Valid when Control is L,I,1,2,T,C
• CountSelected, None
  • Number of selected items.
  • Valid when Control is L,I,1,2,T,C
• CurrentPath, Special
  • Current location.
  • Valid when Control is L,I,1,2,T,A
  • Special is a paramter to resolve this to the full path and not just "Desktop", etc.
• CurrentText, None
  • Get current Address Bar Text.
  • Valid when Control is A
  • Just so the Address Bar isn't left out.
• FocusedBase, None
  • Base name of the focused item.
  • Valid when Control is L,I,1,2,T,C
• FocusedControl, None
  • The currently active control.
  • Valid when Control is X
• FocusedExt, None
  • Extension of the focused item.
  • Valid when Control is L,I,1,2
• FocusedItem, None
  • Full path\name of focused item.
  • Valid when Control is L,I,1,2,T,C
• FocusedName, None
  • Name of the focused item.
  • Valid when Control is L,I,1,2,T,C
• FocusedPath, None
  • Path of the focused item.
  • Valid when Control is L,I,1,2,T,C
• FocusedPos, None
  • The position of the focused item.
  • Valid when Control is L,I,1,2,T,C
• FocusedVer, Pattern
  • Version of the focused item.
  • Valid when Control is L,I,1,2
  • If pattern is used the version will be appended or will replace "*".
• List_CopyTo, Delimiter
  • Copy/Move/Backup MRU list.
  • Valid when Control is X
• List_HiliteFolder, Delimiter
  • List of highlighted folders and their colors.
  • Valid when Control is X
• Pane, None
  • The number of the active list pane.
  • Valid when Control is X
• PaneConfig, None
  • Path to this pane's data files.
  • Valid when Control is L,I,1,2
• SelectedNames, Delimiter
  • Names of the selected items.
  • Valid when Control is L,I,1,2,T,C
• SelectedPaths, Delimiter
  • Paths of the selected items.
  • Valid when Control is L,I,1,2,T,C
• Sort, None
  • Current sort order.
  • Valid when Control is L,I,1,2
• Tree, Delimiter
  • Full path(s) or name(s) of all items in tree structure.
  • Valid when Control is T,C
  • For Catalog it would generate a simple list Category\Name or similar.
• VisualFilter, None
  • Get current Visual Filter.
  • Valid when Control is L,I,1,2

Notes:

• Path for when the Catalog is the control refers to "Category\ItemName".
• The Focused infos apply to the focused item, thus dropping the "and currently selected" requirement.
• Obviously this is only of minimal use for the Catalog, Address, and Tool Bar currently, but why close the door at this time?
• There can certainly be other possible Infos, but I'm sick of listing them.

Thus nothing old should be broken here.
We gain a lot of new information that will be available in an XY-var via <GCI...> and ditch some of the inconsistency.
We gain a scripting command that is a lot more powerful albeit slightly more confusing and difficult to document.
This should also eliminate some of the damage should a new control ever be added.

TheQwerty wrote:Regarding the XY-vars for inactive panes, I think we should take a broader approach...

Don't you have any work in the garden?

Thanks for breeding out this one -- looks good! I'll think about it...

admin wrote:

TheQwerty wrote:Regarding the XY-vars for inactive panes, I think we should take a broader approach...

Don't you have any work in the garden?

You know I frequent the forums as a way to avoid doing actual work!

I had been thinking about how I'd like to see this implemented for a while now but hadn't really fleshed it out entirely. Figured I better do so and submit my thoughts before you went off and did something that may have been entirely different.

zer0 wrote:Nah, I hate to say this, but both of you are slightly incorrect. There are ways to highlight the edits in ways that would catch the eye. J_C_Hallgren manages to do it and so do I. Besides, this is a forum to have an intelligent discussion, not Twitter But hey, admin approves, so I guess it's cool.

Thanks zer0! But in this case, I think Stefan might be excused since each post addressed a separate item/issue and there was about 10 min between the two, so it's likely that someone may have read the first one and cleared the "new post" flag...

When I apply an Addendum or such, it's most likely when I've just found/realized something that changes/corrects/updates what I've written and not something added such as a new point as Stefan had...and I try to mark it with some color so it's obvious that I've tweaked the post.

What I personally find a distraction is a very lengthy quote followed by a handful of words...I try to 'downsize' the quote in many cases to just the key point I'm addressing or to make the context relevant.

The forum software does not set a "new post" flag after an Edit. That's the problem. Therefore making a new post is a safer way to be seen.

I think that due to the forum having relatively small userbase it's acceptable to allow double-posting. However, what about when the community will grow to larger proportions? I know a forum with hundreds of thousands of users and double-posting there is strictly forbidden. We also don't have a moderating team. Perhaps we should have a code of conduct, with edits being in made in specific colour (red?) so the eye would notice those instantly.

Anyway, apologies for that little thread-hijacking. Back on topic of DP desires...

DualPane Color of tabs and background

My Setting:
I have set "Configuration > Interface Colors > Tab headers background" to an kind of very light yellow.
I have set "Configuration > Interface Colors > Other > Inactive Pane" to an kind of very light gray.
That's nice!

Problem:
But since the inactive pane still shows the tab header the same color as active tab is irritating me.

Question/Poll:
* if possible should/could the header of the current inactive tab became the same color of the inactive pane too, if set?
* Or alternative an standard gray color....maybe?
* Or an new option [Inactive tab], that way i could also chose not to color the whole background of IP but color the inactive tab only.
(Then the colored tab would be the only identification what is active and what not. Or in combination with colored bg)
Yes, I would like to test this since right now my inactive pane looks pretty chequered
since the current sorted column is not grey but still white.

What do you think?

Just an additional remark: The majority of users will never touch the "XYplorer Classic" style for tabs, so they cannot color the background of their tabs anyway.

Stefan wrote:Problem:
But since the inactive pane still shows the tab header the same color as active tab is irritating me.

I have had same issue but it's not been enough of an irritation to create a thread, but now that you've mentioned it, I'll agree that it could be improved.

Question/Poll:
* if possible should/could the header of the current inactive tab became the same color of the inactive pane too, if set?
* Or alternative an standard gray color....maybe?

I think the ability to set specific user defined color would be best, so I could pick a light-medium gray (lighter than active but darker than others)...

I use the XY classic as it's my only real choice given that I'm still back on W2K...

admin wrote:Just an additional remark: The majority of users will never touch the "XYplorer Classic" style for tabs, so they cannot color the background of their tabs anyway.

but we can change the text color.