newsbin.com

In the latest beta (10) using Ctrl-R to read a post is not working for me. Worked fine in all previous V6 betas that I recall. I can still read by right clicking and using the pop-up menu, but Ctrl-R is much more convenient.

BTW, thanks for adding back the search box in the download list!

works for me in a post list, where doesnt it work for you?

In the post list.

tried renaming the workspace.xml and trying it then?

i just loaded up a group and ctrl+r on an nfo and it worked

Haven't tried that. Neglected to mention I'm running W7 64-bit. Something peculiar to that build maybe?

Nope. That's all I run. 64 bit is actually the primary platform. It's 32 bits that doesn't get as much testing.

Renaming workspace.xml worked. I noticed that the shortcut ID for Ctrl-R in the newly created xml file is different than in the older one. Thanks, Richy.

Until 6 released, the Id's will get changed from time to time. Good call though.

rchambers wrote:Renaming workspace.xml worked. I noticed that the shortcut ID for Ctrl-R in the newly created xml file is different than in the older one. Thanks, Richy.

That fix worked for me. Making a new workspace.xml messed up my windows but I just got the new ID and put it in the old Workspace.xml. Now I have my docked windows and Ctrl+R too!

I also fixed Ctrl+l for displaying posts window from the Groups list.

I downloaded a free xml editor. Took an xml file created by B11 after I renamed the workspace.xml that had my proper windows setup. Copied the entire <Shortcuts></Shortcuts> scheme 38 section to the clipboard.

Loaded the workspace.xml with the good window placements, deleted the shortcuts section and pasted in the new one.

Ctrl+r and Ctrl+l are working. So far so good.

Just FYI, it's probably going to be a better idea to reset the GUI rather than manually fiddling with the workspace file in the long run. That way you're in line with everyone else and not working with a custom version. I'm sure it's fine for now, but I would reset everything at some point. Good chance you'll end up chasing your tail in future.

DT

DThor wrote:Just FYI, it's probably going to be a better idea to reset the GUI rather than manually fiddling with the workspace file in the long run. That way you're in line with everyone else and not working with a custom version. I'm sure it's fine for now, but I would reset everything at some point. Good chance you'll end up chasing your tail in future.

DT

I'm not going to manually move my windows every beta update. When stable comes out I'll do whatever I have to do.

MilesAhead wrote:

DThor wrote:Just FYI, it's probably going to be a better idea to reset the GUI rather than manually fiddling with the workspace file in the long run. That way you're in line with everyone else and not working with a custom version. I'm sure it's fine for now, but I would reset everything at some point. Good chance you'll end up chasing your tail in future.

DT

I'm not going to manually move my windows every beta update. When stable comes out I'll do whatever I have to do.

I found it's just as easy to go the other way. Save the workplace.xml with current docked window info etc.. Let the new beta create workplace.xml file. Copy and paste the docked window info. Only takes a few seconds. Way better than manually positioning windows. That way all the shortcut and other info is current.

You know, you can do whatever you'd like, but you're completely missing or ignoring the point of my comment. It's a beta, things can change. You're probably going to be fine, but at some point you might start getting odd behaviour. It might lead you, and others here, on a wild goose chase because there's something unique you've fiddled and you missed it. In the end, you'll need to reset it anyway.

It's no big deal. It's more about good testing behaviour than anything - the idea is to minimize deviation from the baseline as far as configuration files that are auto generated as much as possible. It's your choice, though, carry on.

DT

DThor wrote:You know, you can do whatever you'd like, but you're completely missing or ignoring the point of my comment. It's a beta, things can change. You're probably going to be fine, but at some point you might start getting odd behaviour. It might lead you, and others here, on a wild goose chase because there's something unique you've fiddled and you missed it. In the end, you'll need to reset it anyway.

It's no big deal. It's more about good testing behaviour than anything - the idea is to minimize deviation from the baseline as far as configuration files that are auto generated as much as possible. It's your choice, though, carry on.

DT

I didn't miss the point at all. Everyone already knows Control+r and Control+l don't work. I don't see what point is served by forcing me to double click the mouse to open the posts list. To me that's the "odd behavior" not when the program works as expected. If you want to position your windows by hand that's up to you. But I'm a programmer so to me it's no big deal to do it out of script.

Ctrl-R and Ctrl-L both work fine. I just used them. They work fine if you delete Workspace.xml. Maybe there's some hidden meaning in your comment I'm just not getting.

Quade wrote:Ctrl-R and Ctrl-L both work fine. I just used them. They work fine if you delete Workspace.xml. Maybe there's some hidden meaning in your comment I'm just not getting.

I know they work now. (edit:: sorry, I should have used past tense.)

DT was saying beta was all about reporting problems. I pointed out the problems were already reported "Control+r not working" etc. and that isn't interfered with by setting the program in a usable state. If he sets the windows by hand and closes the news reader, workplace.xml will be the same as if I copy the settings if the window positions, sizes and states, toolbars, are the same etc... Otherwise a settings file would have no point. I don't see the virtue of doing it "the hard way" every update when I can just copy & paste the window positions. It's just 2 doors that go to the same kitchen.

Got it. Thanks.