Author Topic: MAPVIEW upgrade  (Read 85552 times)

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #450 on: October 04, 2019, 01:55:05 am »
hm. I can't get it to throw in Debug on win7 ... :\

out of curiosity, since i'll likely put an option in, is there an issue (or not) with a Win10 Release build? these two seem to contradict ...

The issue won't happen, though, if I run the program as Release, rather than Debug.
Quote
- Though, the program still goes on, the issue just manifests itself as a delay (when running Release)

remember there is a short delay by design [SystemInformation.DoubleClickTime]. Are you saying that there is a longer delay, like the OS stalls for a second or two?

I'm trying to understand if this is an issue only in Debug builds,


EDIT:  Here's a commit to master
https://github.com/kevL/OpenXCOM.Tools/commit/4f0d8b6abdd51339bc4408dba54bb4db2075af1f

TopView Option: EnableRightClickWaitTimer (default false)
« Last Edit: October 04, 2019, 03:35:28 am by kevL »

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #451 on: October 04, 2019, 06:25:05 pm »
Hi,

hm. I can't get it to throw in Debug on win7 ... :\

out of curiosity, since i'll likely put an option in, is there an issue (or not) with a Win10 Release build? these two seem to contradict ...

remember there is a short delay by design [SystemInformation.DoubleClickTime]. Are you saying that there is a longer delay, like the OS stalls for a second or two?


To be sure, I waited to pull the latest commit and tested what I reported in these conditions: (placing a tile from Topview with right mouse button)

- Windows 10 native, opening Debug\MapView.exe from file explorer: just the short delay, the tile is placed.
- Windows 7 SP1 X64 from VM, opening Debug\MapView.exe from the file explorer:  just the short delay, the tile is placed

Same conditions of course if you run Release\Mapview.exe.

- Windows 10 native, running "run without executing debug" debug from IDE (VS 2019)  just the short delay, the tile is placed
- Windows 7 SP1 X64 from VM, running "run without executing debug" debug from IDE (VS 2019) just the short delay, the tile is placed

- Windows 10 native, running "run debug" debug from IDE: (VS 2019)  the exception is thrown, application won't crash, you can click "continue" two times, the tile is not placed, but the application is still running.
- Windows 7 SP1 X64 from VM, running "run debug" debug from IDE: (VS 2019)  the exception is thrown, application won't crash, you can click "continue" two times, the tile is not placed, but the application is still running.



Looks like is VS2019 debugging being quite picky, could explain the crash I get in Mono doing same thing.
I'm going to test with Mono if I manage to make my Monodevelop in a working condition, then I gladly test on your latest commit.

Hold on...

ADD 1 : for unknown reason, Monodevelop worked again.

- Linux Mint 18.2, Monodevelop 7.8.4, run debug: that's strange... it placed normally a tile, then I did on adjacent tile and the entire application got frozen, Monodevelop does not return a call stack. Could not close from Monodevelop: I had to xkill it.
- Linux Mint 18.2, Monodevelop 7.8.4, run "without debug": I placed various tiles until the application closed itself.

This is valid either if I run the Debug or the Release version: by pressing ENTER I can put all of tiles I want: with RMB the app will crash at a certain time.

If I use Mono outside Monodevelop, at the crash it returns that stacktrace I posted some posts above.


OK, I'm trying now with latest commit...

ADD 2: Basically, now RMB behaves like pressing ENTER: in all of combinations I can put all of tiles I want.
If I set EnableRightClickWaitTimer to true I have the issues as reported above.


In conclusion:

This issue exists, but affects mainly Linux/Mono users, and it is revealed only by Visual Studio 2019.

I don't know how much difficult would be to fix it, but your idea to opt-in the mouse delay is just simple as smart  ;D
Moreover, it made Mono builds much stable.
« Last Edit: October 04, 2019, 06:53:57 pm by osd_daedalus »

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #452 on: October 04, 2019, 09:06:45 pm »
Ok, now we have (or better, you have) settled this, here's a purely cosmetic thing...

Could we have the UseMono also for TopView and TileView? So we can avoid all of those black backgrounds...

And... yes I tried to implement some if(UseMono) but the classes which contain it are internal sealed or private readonly and so can't use same classes from PckView-TopView-etc. I don't want to make a disaster with classes inheritance just for this :)

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #453 on: October 04, 2019, 10:34:52 pm »
excellent ...

Same conditions of course if you run Release\Mapview.exe.

great ...

Quote
Looks like is VS2019 debugging being quite picky,

grr...

( note i use SharpDevelop, not VS -- I'm a fan of lightweight apps that do the job, although #develop has been discontinued )

Quote
it made Mono builds much stable.

sounds about as good as it's going to get at present.

Ok, now we have (or better, you have) settled this, here's a purely cosmetic thing...

Could we have the UseMono also for TopView and TileView? So we can avoid all of those black backgrounds...

And... yes I tried to implement some if(UseMono) but the classes which contain it are internal sealed or private readonly and so can't use same classes from PckView-TopView-etc. I don't want to make a disaster with classes inheritance just for this :)

black backgrounds? i had't heard about that yet

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so

Code: [Select]
    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView. The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.


i've got another project that's been on hold, i think i'm going to bang my head against that for a while :) But if you need a hint or tip on mapview's inner workings just ask,


ps. Monodevelop, I'm guessing, doesn't like getting SystemInformation.DoubleClickTime for whatever reason ... (it is a windows-specific setting but regardless i'm guessing that Linux and Mac have a very similar system-setting that Mono could replace it with)

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #454 on: October 05, 2019, 12:32:10 am »


black backgrounds? i had't heard about that yet


check the screenshot attached :)
The top windows are on Windows, the bottom ones on Linux with Mono.

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so


Code: [Select]
    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView. The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.


i've got another project that's been on hold, i think i'm going to bang my head against that for a while :) But if you need a hint or tip on mapview's inner workings just ask,


I can't guarantee, but I'll gladly attempt to work on it :)

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #455 on: October 05, 2019, 01:35:01 am »
i uh, I couldn't wish that on my ex-girlfriends JUST KIDDING

seriously, i was thinking it was just some BackColors that were black ... but those sprites need to be drawn with a custom algorithm. it's been fixed in MainView already (the app was basically unusable in Mono with black rectangles all over) -- since I know how to do i'll rig it up fairly quickly,



EDIT
hopefully the latest commit will take care of those black backgrounds

as you see it's fairly complicated, or at least nontrivial ...

If you want to see what the fix is at its core, have a look at MapView.CuboidSprite -- functions with "Rembrandt" are regular .net draw routines, those with "Picasso" implement the transparency workaround. In short, pixels that are transparent aren't drawn; the binary data (byte arrays) of each sprite is iterated over, checking for non-zero/non-transparent color-ids

drawing to MainView has to scale each sprite, but the sprites in TileView and TopView are 1:1

I took the opportunity to consolidate redundant code in TopView's Quadrant panel also ...

i didn't test it thoroughly, so please check it (esp. in Mono w/ "UseMono" true),

and if by chance you want to see the full glory, so to speak, of the workaround have a look at MainViewOverlay.OnPaint() -- but don't get confused by #LOCKBITS, since that's purely experimental, non-functional code
« Last Edit: October 05, 2019, 04:03:57 am by kevL »

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #456 on: October 05, 2019, 07:39:32 am »
@daedalus

If you want something to try your hand at, try docking TopView's toolstrip to the top of its container if Mono (cf. screenshot)

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #457 on: October 05, 2019, 12:08:55 pm »
Hi,

well... was much difficult than I expected... I looked at Rembrandt() and Picasso(), but I have thought it was just a matter of interpolation.

Going to testing: now Mono builds behave liks Windows builds. Well done!

Maybe I could manage to dock that toolstrip, and find a better Copy icon, it is so blended with the background it's almost transparent!

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #458 on: October 05, 2019, 10:10:55 pm »
now Mono builds behave liks Windows builds

alrightie. Perhaps we've got decently functioning code on Mono (built natively )

Quote
Maybe I could manage to dock that toolstrip,

first just drag& drop the toolstrip to the top while running Mapview. In windows, those toolstrips can be repositioned to any of the four sides, and they line the icons either vertically (on the left or right) or horizontally (if on top or bottom, of the panel). There should be a handle at the very left (or top) end of the toolstrip ... the toolstrip should snap into place when moved.

I'm wondering/hoping that Mono positions them better along the top of the panel

Quote
and find a better Copy icon, it is so blended with the background it's almost transparent!

y, i notice that also. I think it's just a matter of increasing contrast/saturation (but haven't gotten around to it yet). I like the icons themselves tho .....

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #459 on: October 06, 2019, 12:18:35 pm »

first just drag& drop the toolstrip to the top while running Mapview.

Looks like "that" is the issue...

https://stackoverflow.com/questions/4986087/does-not-move-toolstrip
 
Although very old, I checked and looks like still true: you cannot drag&drop toolstrips in Mono.

So... nothing to do that way. I'm going to look for another workaround...

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #460 on: October 06, 2019, 12:45:50 pm »
hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]
    this.tscPanel.LeftToolStripPanel.Controls.Add(this.tsTools);

'tsTools' is the toolstrip we're talkin' about


/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #461 on: October 06, 2019, 04:09:36 pm »
hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]
    this.tscPanel.LeftToolStripPanel.Controls.Add(this.tsTools);

'tsTools' is the toolstrip we're talkin' about


/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.

That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #462 on: October 06, 2019, 11:09:45 pm »
That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.

good idea (see screenshot)

but that would take a while, so for now ->
https://github.com/kevL/OpenXCOM.Tools/commit/57dadca3ff3a0ae5e1f39b0e6b4cafebe36e0e85


Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #463 on: October 07, 2019, 07:30:08 pm »
That looks like... different from your screenshot.
Looks like good!


Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #464 on: October 07, 2019, 10:04:58 pm »
freaky. All i did was add the toolstrip in the cTor instead of in designer's InitializeComponent()

looks like a bingo ...




must resist urge to delete Windows™


Can I ask you a question... did you have

Code: [Select]
//#define __Mono__

defined (uncommented) for that last Mono build? Because if we don't need #define __Mono__ i'd like to take it out of the code.
at the top of the TopView.cs file
« Last Edit: October 07, 2019, 10:37:20 pm by kevL »