Visit our Popular Forums

wingssail · 23-03-2013, 18:32

Quote:

Originally Posted by dweller

In the routes/waypoint window, if I click on an eyeball to display the route on the screen, I get a pop-up, "Do you also want to toggle the visibility of shared waypoints being part of this route," and the program hangs, whether you click "yes" or "no." Have to force quite the program and re-start it.

For me (using Win7) the program does not hang at this point but it is very slow to toggle the display on and off, the pop up does not seem to make sense to me (what does it mean to toggle the visability of shared waypoints when you are making a route visable?), and some waypointsstill do lose visability when toggling a route to invisable even when you respond "no" to the pop-up.

I have about 30 routes and quite a number of waypoints, most of which are exported and then deleted from the screen to make the program run faster.

I will add the share waypoint visability problem to fly-spray.

nohal · 23-03-2013, 18:46

wingsail...
It does what it says: "route points" existing only in the route you are turning on/off are always turned on/off. But if the route passes a waypoint (one ow those visible on the waypoints tab) you have a choice to turn it's visibility. Do you observe another behaviour?

Pavel

wingssail · 24-03-2013, 04:09

Well, yes, a.) The behavior is different that that. Some of the waypoints, which are also used by other routes, become invisable when the route is made invisable, even when the pop-up reply is "No". I have created a flyspray bug report for this.

b.) That Pop-up seems to me to make sense when you are making a route invisable, (do you wish to keep visable those waypoints which are used in other routes or not?) but it make less than perfect sense in the case that you are making a route visable. Why would you wish to make a route visable while keeping invisable some of the waypoints on that route?

c.) If I was designing this I would think that the pop-up would apply only to those waypoints which are created in the process of creating the route, but waypoints which existed previously, and which are simply used by this route, regardless if other routes use them, should be left visable after the route is made invisable.

To add to the last paragraph, let me explain the situation which made this a problem for me:

I have created a number (15-20) of waypoints which represent racing marks in the area. These marks are used over and over in various combinations for race courses. When a new course is annouced I create a route for it, going around the marks specified. If there is a mark which is used in only one course, then even with this pop-up, that mark becomes invisable when I switch off the route, making it hard to use that mark for another course. So these marks/waypoints should be kept visable no matter what I do with the courses or routes. My work around is to create one course (route) which goes around every mark. Then all the marks are "shared" whenever any other route incudes them. This does not work perfectly, (hense the bug) and even if it did, it does not solve the problem of a mark which is added and used by only one route.

The same is true for navigation aids which are not already on the chart. When I create a waypoint for these it should stay, even if I put a route around it and then later make that route invisable.

I know that this is what the pop-up purports to do but in some cases it is failing.

nohal · 24-03-2013, 07:36

Quote:

Originally Posted by wingssail

Well, yes, a.) The behavior is different that that. Some of the waypoints, which are also used by other routes, become invisable when the route is made invisable, even when the pop-up reply is "No". I have created a flyspray bug report for this.

This would sure be a bug, but I really can't reproduce this behavior... GPX sample, please...

Quote:

b.) That Pop-up seems to me to make sense when you are making a route invisable, (do you wish to keep visable those waypoints which are used in other routes or not?) but it make less than perfect sense in the case that you are making a route visable. Why would you wish to make a route visable while keeping invisable some of the waypoints on that route?

Well... The best answer here is probably "why not?" If I remember well all those arguments that led to implementing this feature at all, people's need differ greatly...

Quote:

c.) If I was designing this I would think that the pop-up would apply only to those waypoints which are created in the process of creating the route, but waypoints which existed previously, and which are simply used by this route, regardless if other routes use them, should be left visable after the route is made invisable.

To add to the last paragraph, let me explain the situation which made this a problem for me:

I have created a number (15-20) of waypoints which represent racing marks in the area. These marks are used over and over in various combinations for race courses. When a new course is annouced I create a route for it, going around the marks specified. If there is a mark which is used in only one course, then even with this pop-up, that mark becomes invisable when I switch off the route, making it hard to use that mark for another course. So these marks/waypoints should be kept visable no matter what I do with the courses or routes. My work around is to create one course (route) which goes around every mark. Then all the marks are "shared" whenever any other route incudes them. This does not work perfectly, (hense the bug) and even if it did, it does not solve the problem of a mark which is added and used by only one route.

The same is true for navigation aids which are not already on the chart. When I create a waypoint for these it should stay, even if I put a route around it and then later make that route invisable.

I know that this is what the pop-up purports to do but in some cases it is failing.

IF the bug exists, this is perfectly understandable, but as I said above, I can't reproduce it... The whole think IS designed so that the waypoints don't (never) disappear disappear with routes until you instruct them to do so. But the waypoint has to be a real waypoint, thing visible on the waypoints tab in the route manager, not just a point part of another route. In that case the behaviour would be as you describe, but it would still be questionable if it's a bug. With that GPX sample, it should be clear immediately.

Pavel

bdbcat · 25-03-2013, 19:18

wingsail/pavel...

After fooling around with this a bit, I agree that offering the "Toggle..." dialog when making a route VISIBLE is probably silly. If you want the route visible, you no doubt want all the associated waypoints visible too.

As built now, one can get to a point where the route legs are visible, but there are no associated waypoints visible or selectable. This is probably nonsense...

However, like Pavel, I cannot reproduce an error in the logic with shared waypoints. A specific (GPX) example would be helpful.

Thanks
Dave

nohal · 25-03-2013, 19:24

Dave...
OK, I will be touching this code soon to make it possible to export more than one selected object, so I will change this behaviour as well...

Pavel

Hakan · 27-03-2013, 14:11

Pavel/Dave...
Status bar bearing to cursor:
winXP
1. The function is working fine in the official download of 3.2.0
2. I fetched today from Git and build for debug, all went well. In debug the distance to cursor is fine but the bearing says: -2147483648 degr. ???
3.I released and copied the exe to my normal running dir and it's running fine but the bearing to cursor says mostly 000 and sometimes 1422 or the same minus as of debug mode.

Any hints?

But the good thing is I'm able to build from source for the first time. Thanks to the dev-wiki and Rick's advices and enthusiasm.

Håkan

nohal · 27-03-2013, 15:16

Ooops... My bad, fix coming as soon as I get out of this firewalled corporate prison...

Pavel

Hakan · 27-03-2013, 15:32

Quote:

Originally Posted by nohal

Ooops... My bad, fix coming as soon as I get out of this firewalled corporate prison...

Pavel

Pavel.. Thanks for your reply and that I wasn't the cause.

And.. No hurry - you know time is one of the few things that is constantly issued without fees.
Håkan

nohal · 27-03-2013, 16:23

Fixed in github master.

Pavel

rgleason · 27-03-2013, 19:08

Pavel or Dave,
Sean (boat_alexandra) was planning on reinstall of wxWidgets and using a newer version. I suggested that he should talk with you before he goes ahead with wxwidgets 2.9 because I had read one situation where a guy trying to run in Mac had done that and had to reinstall wxWidgets 2.8.12. -- Is this true? Should he be installing only wxWidgets 2.8.12? I believe he is running some version of linux...

(I hope he sees this, because I think it sounds imminent, he wanted to get symbols right for debugging lines.)

Thanks.

nohal · 27-03-2013, 19:27

Rick...
Upgrading to wx2.9 at this point would be a major packaging headache as it is not available in repositories of the Linux distributions and we would have to bundle it with OpenCPN (which is bad)... We will probably have to wait until the stable wx3.0 is released and gets to a reasonable amount of distros. Making the code compile against it is actually pretty easy (the result has a couple of glitches in the GUI though) - When I tried a couple of weeks ago it took just a few little changes to the code as the majority of the work was already done because of Mac OS. I like the features of wx2.9, but I really don't see any reason strong enough to overweight the problems if we make it a required dependency for all the platforms at this point...

Pavel

Hakan · 28-03-2013, 00:47

Quote:

Originally Posted by nohal

Fixed in github master.

Pavel

Pavel..
I've still have the same minus value in debug and 000 in release modes for the bearing to cursor.
My preparations, please check:
-Git fetch --all > some updates.
-Git fetch --all > fetching origin
-cmake -G "Visual Studio 10" .. > ok
-cmake --build . > succeeded. 0 warnings 0 error
-VS 10 clean start up project e.g. opencpn. > 6 succeed
-VS10 opencpn debug start new instance > A bunch of "C:\windows\system32\.....dll cannot find or open the PDB file" but I think that's normal?
- Debug version of opencpn is running. Still -2147483648 bearing to cursor.
- Release as earlier as well

???? please advise if it's likely I really have the updated files running. Can I check in the code ?
Håkan