Question [C#] Need help bug tracking this app

[SolarLiner]

Hi,
So I've been working on a scenario generator from TLE elements; and I have a bug I can't seem to find the source of.

Basically, it goes like this:
Once on the main window, the 'scenario properties' such as the name, description and date can be found on the top right button.

Uncheck "Always use system time" to be able to change the date, then change the date.

Change the date to whatever you want, and press OK.

Then, the date picker closes, but so does the scenario properties, and the date isn't changed. (You can check it by opening the scenario properties again, and seeing that the 'Always use system time' checkbox is still checked)

I've been trying for days to track this down, but has not been able to so far. Can anyone help me on this? It'd be awesome

I've made the code available here: https://github.com/SolarLiner/TLEOrbiter
Executables are on the Release tab.

 

[boogabooga]

This does not answer your question, but FYI a scenario generator from TLE elements already exists:

[ame="http://www.orbithangar.com/searchid.php?ID=2617"]Scenario Editor TLE[/ame]

 

[Face]

I've made the code available here: https://github.com/SolarLiner/TLEOrbiter
Executables are on the Release tab.

Can't compile, AOSP is missing. I've found AOSP , but apparently your version on SF is outdated, as it does not implement GetTime and uses the Misc class only internally.

I've fixed the access attributes of AOSP and added my own GetTime implementation from OMP, so I've managed to compile it now.

Your problem is fixed with the attached patch: View attachment doublereturn.txt . This should be importable in SVN or Git.

 

[SolarLiner]

Whoa, this is even better than imagined. Face strikes once again!

I now only realized I forgot to include AOSP in the git... It's the whole project and not only the DLL as I was modifying as well as this.

Now for the diff... It's actually a pretty simple solution, but I don't quite understand why it would close the form at the end of the function, when no Close message has been either sent or received.

 

[Face]

It's actually a pretty simple solution, but I don't quite understand why it would close the form at the end of the function, when no Close message has been either sent or received.

I think it has something to do with cascading modal dialog calls. You called ShowDialog from an already modal dialog. My understanding is that the second modal dialog has the first as parent in the WINAPI native window elements, thus forwarding the appropriate window messages to it.

AFAIK, once the DialogResult is set, the modal dialog gets closed (you don't need those Close calls, see View attachment cancelreturn.txt ). Since the first one gets the window message from the second one handed down, it also sets the DialogResult of itself, thus closing after the GUI message pump ends its round. Setting it back to None avoids this.

I've also fixed the solution, because it was still pointing to your other directory, not the one in the repo: View attachment solutionfix.txt .

cheers,
Face