@meltdown03 Thanks for reporting it. I've just now built wxWidgets 3.2 from source. I see the same message and backtrace as you do, but I'm doubtful that that indexing error is causing your display-size problem, because when I click the option to continue I get a normal-size VirtualAGC GUI display. The VirtualGUI acts normally when I use it to run the AGC simulation. (Of course, I still will try to fix the indexing problem anyway.) So there's presumably some significant difference between your computer's setup and mine, aside from the obvious Arch vs Mint difference.

One question for you ... I notice that when I build wxWidgets it seems to want to preferentially use GTK+ 3, which I don't have, but it's willing to fall back on GTK+ 2. That seems to me to be something that could affect the display size. My question for you is this: Is wxWidgets trying to use GTK+ 2 or GTK+3?

My idea is that VirtualAGC/VirtualAGC.cpp does have code (I'm thinking of the SCALE_BITMAP macro at lines 341-348 in the version I'm looking at) for trying to detect the display size and adjusting the size of widgets accordingly. If there's some bad interaction between wxWidgets and GTK+, it may not be getting the correct sizes.

You can test out this idea, or at least the idea that the screen size is being interrogated wrong somehow, by finding the couple of places that VirtualAGC/VirtualAGC.cpp uses Size.GetHeight() and Size.GetWidth(), and simply hard-coding whatever screen size you like instead. Those values are in pixels.

Another thing you can try is to directly run the simulation rather than going through the VirtualAGC GUI — which ultimately does nothing except to take your selections, create a shell script called simulate, and then run it. For example, here's what it creates when choosing all the default options for running the Apollo 11 LM software:

#!/bin/sh
PIDS=
rm LM.core
rm CM.core
../bin/yaDSKY2 --cfg=LM.ini --port=19797 &
PIDS="$! ${PIDS}"
../bin/yaAGC --core="source/Luminary099/Luminary099.bin" --port=19797 --cfg=LM.ini &
PIDS="$! ${PIDS}"
../bin/yaTelemetry --simple --port=19800 --spacecraft=LM &
PIDS="$! ${PIDS}"
export PIDS
../bin/SimStop

You might try putting that into a file called (say) ~/VirtualAGC/Resources/simulate, making it executable, and then from a command-line doing

cd ~/VirtualAGC/Resources
./simulate

@meltdown03 Oh! It looks like SCALE_BITMAP is never actually used anywhere. So don't bother with it.

@meltdown03 Try this: In VirtualAGC/VirtualAGC.cpp, around lines 456-457, you'll find something that looks like the following:

  if (Points < 8)
    Points = 8;

Change both of the 8's to 9's, and then redo the make install. When I do this, the index error goes away, and the fonts are a little bigger in the VirtualAGC GUI. I think that what the index error may have been telling us is that there's no longer an available font that's size 8, but it just so happens that my system falls back on a font size that's more readable than your system does.

Thanks, I'll give that a try. I wonder what changed then, because it used to work. I'm using GTK3.

I just saw your last post, I changed it but everything is the same, I did a make clean first even. Maybe I have a config file somewhere with a bad font.

Well, if 9 didn't work, perhaps 10 would.

I tried 10 too and 7, what font do you use and the size?

I ran the command gtk-query-settings and got mine, it was gtk-font-name: "Cantarell 10"

I've just now installed gtk 3, and right now gtk-query-settings tells me gtk-font-name: "Noto Sans 9". I have no way of knowing what it would have said before when I was reporting that VirtualAGC worked for me with gtk 2.

But also, VirtualAGC has just now finished rebuilding with the rebuilt wxWindows based on gtk 3. It still works. Moreover, it works with either the 8's or the 9's, without any index error.

Curiouser and curiouser.

The GTK settings.ini file is in $HOME/.config/gtk-3.0 for me. That's where i can set the font, I tried setting it to the same as you, but sill has the error and looks the same

I don't seem to have that file. The directory is there, but no settings.ini. I have a global settings.ini in /etc/gtk-3.0/, but there's no font in it. In fact, I can't find any file with that info in it.

I wonder, though ... perhaps you need to log out and log back in for the changes to take effect. After you change the settings file, does gtk-query-settings report the changed font?

I had to change the font through my system settings (Gnome Tweaks actually) and I am able to see the buttons if I pick Noto Sans, size 10 as my font. Size 9 or my normal font doesn't work like it used to. I still get the Assert error everytime though and much of the text on the GUI is barely readable because the color is way too light on a light background. Also the DSKY buttons are weird now:

I switched to the non-dark version of my default Adwaita theme and now the color is ok but the scaling is still all off and all my other apps are a different color now, lol. I do remember that it was always hard to read the GUI screen before, but at least the check marks were there, haha.

Well, some stuff is supposed to be grayed out, but in your screenshot it's not even the right stuff grayed out. I think. It's hard to tell because the checkboxes have no checkmarks in them, and the graying is context-sensitive. But it looks like the stuff that's supposed to be grayed out is displayed correctly, while the full-black text is what's showing up as really light. Bizarre!

As far as the DSKY is concerned, it was displaying normally before I started using gtk 3, but does look somewhat similar to the screenshot of yours (but with reversed colors) now.

However! That's with the half-size DSKY button selected, as I see it is in your screenshot. With the full-sized DSKY button selected, the DSKY looks perfectly normal to me. Perhaps you could try that and see if it's better for you. Whether or not it's better, I guess I'll have to look into the half-size problem.

Also, the "DSKY Lite" setting for the "AGC CPU Bus/Input/Output Monitor" that I think you have checked looks perfectly fine. Though admittedly I can't quite recall what it was supposed to look like. 😄

I think I was using the Full DSKY before, it looks fine. Thanks for that. Thee were a couple times when I switched back to the dark theme on my system that I stopped getting the invalid index errors. I can't recreate that now though. I can just ignore the index error for now. I also just use the Tab key to get to the hidden "Run" button too, lol. Do you anything about this repo https://github.com/ThymoNL/AndroidAGC ? Your code is in it and I have an open issue for the 8 and 9 DSKY buttons not working

Huh? The Run button isn't hidden in your screenshot! But there are several command-line options for VirtualAGC that affect the layout of the GUI, and perhaps using one of those would make the button accessible again.

Regarding AndroidAGC, no I don't know anything about it. If I was told, which is entirely possible, I have since forgotten. However, any code of mine that's there would just be for the CPU simulator anyway; my DSKY code wouldn't have been useful.

Also, I've been thinking about your comment about downgrading wxWidgets. With wxWidgets, you can have multiple versions of it installed simultaneously, and you can select which one of those versions is used by any given build. Or you can set which version you want to use as the default for all builds. None of which affects any software already built with a different version at all. For example, on my main computer, I have 4 different versions of wxWidgets installed right now, and on the virtual machine I used to build VirtualAGC I have 2 different versions.

So if you want to return to the olden days when VirtualAGC and the DSKY worked better for you, that might be the way to go. And you don't have to depend on Arch packages (or whatever Arch has), because it's exceedingly easy to build wxWidgets from source. Just download 3.0 or 2.8 from wxWidgets.org, build it, and install it ... which will automatically set the latest one you installed as the default for new builds of wxWidgets-based programs. And then rebuild VirtualAGC yet again.

Of course, "exceedingly easy" has a "famous last words" kind of flavor to it. Exceedingly easy if all of the prerequisites are installed already.

I got back to the way it was before the wxWidgets upgrade by using the Arch Archive Repo (lets you pick a past date) It was using GTK2. The half DSKY worked ok then and the GUI was all there but scruntched up:

@meltdown03 I was wrong, the assertion error for the bad index is nothing to do with the sizing issue. You were close to being right with your original suggestion that it's something to do with VirtualAGC.cfg. Basically, it happens when VirtualAGC.cfg doesn't exist at all. VirtualAGC.cfg gets written when you exit the VirtualAGC GUI with its EXIT button. It doesn't get written when you exit using the X on the window border. (I think that's by design, but I can't recall any rationale for it.) So if you kept hitting X because you couldn't get to the EXIT button, you'd keep seeing the problem.

Anyway, I've just pushed the fix for the assertion error to the repository. I haven't looked at the other problems yet.

Heres a new error when I try to run yaTelemetry in "Retro" mode, it does still work after I click continue though.

ASSERT INFO:
/build/wxwidgets/src/wxWidgets-3.2.0/src/common/wincmn.cpp(2488): assert ""!m_containingSizer"" failed in SetContainingSizer(): Adding a window already in a sizer, detach it first!

BACKTRACE:
[1] wxWindowBase::SetContainingSizer(wxSizer*)
[2] wxSizer::DoInsert(unsigned long, wxSizerItem*)
[3] wxEntry(int&, wchar_t**)
[4] __libc_start_main

The sizing issue for yaDSKY2 (and for yaDEDA2) appears to be a bug in wxWidgets, wherein if the window has been configured to allow the user to not be able to resize it (which these were, since the positions of everything had been crafted to look like the original device), then the window can be the wrong size. This may be the problem with your bad RUN/EXIT buttons in VirtualAGC as well, but since I don't see that problem myself it's hard to say.

I've just pushed a change in which all three of those are now resizable by the user. It fixes the half-size DSKY and DEDA for me. And even if it doesn't fix your RUN/EXIT buttons, at least it should allow you to make the window bigger so that you can see them.

I can resize it now to see my buttons! Thank you. Is there a way to build it with debugging symbols in so I can step through the code with GDB? I tried the DEBUG_BUILD env var and adding -g and removing all the strip commands but then it won't build for some reason

My experience with wxWidgets and gdb is that it's almost useless to try and debug wxWidgets-based programs that way. These are all event-loop programs that don't do anything in a reasonable order in a way that is recognizable unless you're absolutely steeped in wxWidgets lore (which I'm not). Some code is executed that you think should do something, and then half a second later it actually does it. After my initial experiences, many years ago, I completely gave up on it. What I've been doing for my debugging today is to strategically insert modal popups, like so

wxMessageBox(wxT("SOME MEANINGFUL MESSAGE"), wxT("Warning"), wxICON_WARNING);

to just pause execution and display whatever I want to at whatever points in the program I like. It's a hassle, but it works.

Also, I think what you're asking for may involve building wxWidgets itself with debugging symbols enabled. I'm not sure I ever knew.

So while I don't think the answer to your question is necessarily "no" in a theoretical sense, in a practical sense I'd prefer not to mess with it at this moment.

Thanks, I appreciate that. It's a big help. I've just spent several hours trying to coax the "normal" version of yaTelemetry to size itself properly, and frankly, the novelty has worn off. So knowing where to look in the "retro" version, albeit for a different problem altogether, doesn't hurt. 😄

I've just pushed changes that hopefully fix both the "normal" and "retro" invocations of yaTelemetry. But as far as the "retro" version is concerned, I've disabled the frame around it that was supposed to look like the borders of a CRT. The graphics didn't line up correctly and it was too big for most folks' screens anyway, so it just didn't seem worth messing with.

Here is the contents of one of the files ($HOME/VirtualAGC/Resources/cFLfNV):

-94750098277977 10 60400
4 11 20000
0 13 100
720 13 0
0 13 100
1045 13 0
1 13 100
1044 13 0
1 13 100
1045 13 0
1 13 100
1046 13 0
0 13 100
1046 13 0
1 13 100
1055 13 0
0 13 100
1048 13 0
0 13 100
971 13 0
81 13 100
966 13 0
81 13 100
965 13 0
80 13 100
969 13 0
80 13 100
965 13 0
81 13 100
966 13 0
82 13 100
973 13 0
80 13 100
974 13 0
0 13 100
1048 13 0
0 13 100
1049 13 0
0 13 100
1046 13 0
0 13 100
1063 13 0
0 13 100
1053 13 0
1 13 100
1048 13 0
0 13 100
1051 13 0
0 13 100
967 13 0
80 13 100
990 13 0
0 13 100
1053 13 0
1 13 100
1044 13 0
1 13 100
1048 13 0
0 13 100
1045 13 0
0 13 100
1049 13 0
0 13 100
1045 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1044 13 0
1 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
81 13 100
964 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
0 13 100
1045 13 0
1 13 100
1044 13 0
0 13 100
1046 13 0
80 13 100
964 13 0
1 13 100
1044 13 0
81 13 100
964 13 0
81 13 100
964 13 0
81 13 100
964 13 0
80 13 100
965 13 0
80 13 100
964 13 0
1 13 100
1044 13 0
80 13 100
964 13 0
81 13 100
964 13 0
81 13 100
964 13 0
81 13 100
964 13 0
80 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
964 13 0
81 13 100
1045 13 0
0 13 100
1046 13 0
0 13 100
966 13 0
81 13 100
1044 13 0
1 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
1 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1043 13 0
1 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1056 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1046 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1043 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1045 13 0
0 13 100
1044 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1045 13 0
0 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
1 13 100
1044 13 0
80 13 100
965 13 0
80 13 100
964 13 0
1 13 100
1044 13 0
80 13 100
966 13 0
81 13 100
964 13 0
81 13 100
964 13 0
81 13 100
965 13 0
81 13 100
964 13 0
81 13 100
964 13 0
81 13 100
965 13 0
80 13 100
964 13 0
81 13 100
964 13 0
80 13 100
964 13 0
81 13 100
964 13 0
81 13 100
964 13 0
80 13 100
964 13 0
81 13 100
1044 13 0
1 13 100
1044 13 0
0 13 100

Your last post is the key observation. The only writing of files that yaDSKY2 does is if it is put into what you might call "recording mode", wherein it writes out a file of every message received from or sent to the AGC, for potential playback later. This appears to be one of them.

The problem is that starting a recording operation requires user intervention. You have to touch one of the indicator lamps, then go through a modal dialog to select the filename, and then hit OKAY. It doesn't just start on its own.

Possibly the internal variables associated with that are no longer being initialized under wxWidgets 3.2, and hence yaDSKY2 incorrectly believes it's supposed to be recording, and is using a garbage file-descriptor to do so.

Rather than supply a potential fix for this immediately, we need to find out for sure if that's what's happening. If it is, there are potentially other things not being initialized, such a font colors, which could explain some of your other problems.

That makes sense, clicking the Tracker button on the DSKY shows that it starts a recording, then If I click it again is says it stopped, but does not give an option to pick the file name, The Prog light lets me load a .canned file and shows the file open dialog.

Oops! Well, I was speaking from memory rather than looking at the details.

NP, I just didn't want you looking in the wrong area of the code.

In yaDSKY2, down around line 1450, I've added the 3 lines involving message boxes in my local version of the code:

	  Fin.Close ();
	}
    }

  wxMessageBox(wxT("I am here"), wxT("Info"), wxICON_INFORMATION);
  if (MainWindow->recordingFileOpen)
    wxMessageBox(wxT("Recording"), wxT("Info"), wxICON_INFORMATION);


  MainWindow->Timer = new TimerClass ();
  MainWindow->Timer->Start (PULSE_INTERVAL);

What these do is that when yaDSKY2 starts up, first pops up a box that says "I am here", and then if recording is going to start it pops up a second box. For me, so far, that 2nd box never pops up.

I'd suggest you add the lines yourself and try it a few times until you get the bogus error messages, and see if they're correlated or not. I think it's the Timer class that handles the i/o with the AGC, so I don't think you can get any bogus error messages before the "I am here".

Oh, and the popups will be behind all other windows, so you have to move everything out of the way to see them.

I tried it, the first time it was ok, the second time it said "Recording" also. Then after I click ok on that popup, the error showed

It seems to happen less often, maybe 15-20% of the time now, but it also seems completely random.

It seems to happen less often, maybe 15-20% of the time now, but it also seems completely random.

Are you saying it happens 15-20% of the time without getting the recording popup first?

Yes, that's what I meant. I've just pushed a change that always initializes the variable in yaDSKY2. (It also moves the "Simulation Status" window of VirtualAGC to the upper left corner of the screen so that it doesn't cover up all the other windows all the time.) Hopefully that will fix this particular problem at least.

Whoops! Spoke too soon. There was a bug.

Okay, I've pushed that change.

In addition, on the theory that the reason your VirtualAGC text has the wrong color is because wxWidgets 3.2 isn't initializing the default color correctly, I now try to explicitly initialize the default color to black. Also, because I'm not sure I'm doing that correctly, I separately explicitly initialize the color of the heading "AGC Simulation Type" to black, and I'm sure (I think) that I'm doing that correctly. See if it fixes your colors, or at least the color of the "AGC Simulation Type" heading.

Actually, I am sure that I was doing it correctly, because here I can use this technique to change the color to blue or green or whatever, an idea that I had overlooked. So I have high hopes.

I can read the text now and no more random recording errors. Still no checkboxes though. EDIT: And the buttons are still cut off

The problem with checkboxes is that there's nothing I can discover that can affect their styling. They expect you to just take what they're offering and like it. Want an X rather than a checkmark? No! Want a different color for it? No! Want anything else for it? No!!!! Which means that there's nothing I can change the initialization of.

But ... checkboxes inherit some of the styling of the classes the checkbox class belongs to, so I can give you random things to try, even though they do nothing at all when I try them here.

One thing is that a checkbox is a type of control, which is a type of window, and windows can be styled so that their backgrounds are transparent. That could mean that a white checkmark ends up on top of a white background, even though the wxWindows docs swear that a transparent background is most definitely not the default. Anyway, you can try this: down around line 590 in VirtualAGC.cpp, add the following SetBackgroundStyle line:

  .
  .
  .
  DeviceAcaCheckbox = new wxCheckBox(this, ID_DEVICEACACHECKBOX,
      wxT("Attitude Controller Assembly"));
  
  DeviceAcaCheckbox->SetBackgroundStyle(wxBG_STYLE_ERASE);
  
  JoystickConfigure = new wxButton(this, ID_JOYSTICKCONFIGURE, wxT("Handler"));
  .
  .
  .

Obviously, if that does anything at all, it would only affect the styling of the Attitude Control Assembly checkbox. So check that box a few times and see what happens.

And while you're at it, go ahead and add the following line at the same place:

DeviceAcaCheckbox->SetBackgroundColour(wxColor(255,0,0));

If it worked, it would change the background to red, just in case it's set to white now. It does nothing at all for me.

I tried it but it's the same. It is not a big deal, I can try googling around for wxWidgets and checkbox issues with GTK3 and themes. lol. For now it works that the outside of the checkbox turns blue when checked.

I tried that line also, but it looks the same

And while you're at it, go ahead and add the following line at the same place:

DeviceAcaCheckbox->SetBackgroundColour(wxColor(255,0,0));

If it worked, it would change the background to red, just in case it's set to white now. It does nothing at all for me.

I hope this doesn't sound like a cop-out, but even if it does, and even if I have suggested it before: Maybe you should reconsider building wxWidgets from source rather than relying Arch's binary package. It sounds to me like maybe it was tweaked somewhat by the Arch maintainers, and maybe those tweaks were less than great.

The source is here and the instructions are here, and the only variation for me from those instructions was to use ../configure --with-sdl instead of just ../configure. I had made a wisecrack before about getting all of the dependencies, but I'm not sure there are any dependencies to get, since wxWidgets actually bundles all or most of the dependencies it needs into the source tarball.

No it doesn't, you have to be able to reproduce it to test and fix it, plus it works on your system. I also don't know if if it's specific to this program since I don't have anything else that uses wxWidgets.

With that said, should I close this issue now since it's not technically broken?

Sure! It can always be reopened if necessary, or a new one can be opened for new issues.