Brian,
This doesn’t quite fit the existing topic categories here–maybe could create a new category for source code development?
Anyway, @Munkhtamir has motivated me to do a bit more work on QtAgOpenGPS, so I’m working on updating the C++ version of the classes. This is a question about the source code, specifically, CTram.cs. In CreateOuterTram(), it refers to mf.tram. As far as I can tell there is only one instance of CTram at this time (“tram” in the main form), so currently “mf.tram” is the equivalent of “this.” Is that correct? Are there further plans for for CTram that will involve multiple instances of CTram, and thus CreateOuterTram() wants to refer to a particular master instance for this function’s calculations?
thanks,
Michael
I also see a reference to mf.ABLine inside of CABLine. I can only see one instance of CABLine, so mf.ABLine is redundant in CABLine?
To make things very simple every item - even if one like tram or abline etc - upon creation gets a pointer to the main form (mf). So every class has a reference to the main form object - not a copy of, just a reference. This allows while being in the tram class to access any other classes public variables.
If you were in tram and wanted the heading of the abline, all you do is mf.abline.abheading and you have access to that class property since you have reference to the class (FormGPS) that created it.
Sorry i missed this post - getting easier to miss a lot of posts now.
Thanks. My question was more subtle though. Why does code in CTram.cs refer to mf.tram, for example. There’s only one instance of CTram that I can find (in the main form), so why does CTram refer to mf.tram instead of just accessing the member variable directly?
I see this in many of the other Classes also. I’ve just been chopping out that reference entirely, essentially replacing it with “this” when I see this kind of access, since I know there’s only ever one instance of these particular classes.
Oh, i just looked, originally there was no tram class, all was in abline and curve classes, and other places. so it was just cut and paste back to where it is now and not edited.
You don’t need “this” either.
the line mf.tram.outArr[i].northing is exactly the same as outArr[i].northing and this.outArr[i].northing within the tram class.
Have you seen the work Christian is doing with qtAOG?
Yeah that’s what I meant. I just used “this” to demonstrate what I meant.
Haven’t seen his work, not. That’s unfortunate! In the last week I’ve updated every class to be in sync with AOG (well as of a couple of weeks ago). So likely we’ve duplicated a lot of things. I’m committing everything to my QtAOG repo, but it’s currently under a branch. I just need to update the OpenGL main drawing functions and then it should run again, albeit without GUI support for any of the features just yet, but Muhtamir is wanting to work on that bit.
As always a lot of TODOs to fill in missing functionality. Like I haven’t implemented OpenGL font drawing texture stuff yet but that shouldn’t be too hard. I abstracted the pipeline OpenGL calls in QtAOG so they are pretty simple now. Might be something AOG wants to adopt in the future, since that opens the door for all kinds of platforms that don’t support immediate mode.
Also I I figure out how to fairly easily move the entire rendering left or right, when floating GUI elements would otherwise block the view of the tractor.
Kind of forgot how fun working with Qt is.