MAPVIEW upgrade

[kevL]

oh, Descriptor.GetTerrainDirectory(string) is for getting the path to alternate TERRAIN dirs

That is, a terrain can be taken from any directory (as long as it's called TERRAIN) and it can be different from the Map's basepath. So, in MapTilesets.yml a terrain can be specified in one of three ways:

Code: [Select]

    terrains:
      - U_EXT02 # use the TERRAIN dir under the Configurator's basepath


Code: [Select]

    terrains:
      - U_EXT02: basepath # use the TERRAIN dir under the Map's basepath


Code: [Select]

    terrains:
      - U_EXT02: C:\MyTerrains # use the TERRAIN dir under "MyTerrains"

the codeblock you quoted above happens in the 2nd case

It looks okay atm, i think the bug happens higher in the chain ... I'm going to search for instances of SharedSpace.ResourceDirectoryUfo and SharedSpace.ResourceDirectoryTftd ... see if i can spot where one of them doesn't make sense,

[kevL]

I found some issues, daedalus. Don't bust yer head over it, it's a complicated issue. i'll start punching away at it ...

i might want for a true TFTD Map/Routes + terrains but i'll just work with a mockup for now (or I might even have some TFTD tilesets kicking around..), Basically it seems that the TileGroupManager.LoadTileGroups(string) isn't differentiating between UFO and TFTD.

[osd_daedalus]

I found some issues, daedalus. Don't bust yer head over it, it's a complicated issue. i'll start punching away at it ...

i might want for a true TFTD Map/Routes + terrains but i'll just work with a mockup for now (or I might even have some TFTD tilesets kicking around..), Basically it seems that the TileGroupManager.LoadTileGroups(string) isn't differentiating between UFO and TFTD.

Yes, reading at your explaination about basepath I started to ask myself "will the - U_EXT02: C:\MyTerrains # use the TERRAIN dir under "MyTerrains" return true sometimes or does it suffer from the same issue? In the last case is not only about TFTD but for every resource in another folder that is not UFO"... and then I started to panic thinking about a complete overhaul of the function 

Waiting for your solution, then

[kevL]

... and then I started to panic thinking about a complete overhaul of the function 

lol, terrains are not pretty

Code: [Select]

    // get the Terrains of the tileset ->
    terrainset = new Dictionary<int, Tuple<string,string>>();


EDIT: will ya look at that -- that's a typo and a half ...

setting Pal outside the braces ... an oddity of the current code is that originally (MapViewI) it used Palette to determine if the gametype is UFO or TFTD. I've been gradually replacing that with an explicit Group/GameType variable. But somethings still rely on Palette, and that typo is effectively setting any GroupTypes (that rely on Palette to be correct) to GameType.Ufo ....

I'll poke around looking for any other self-inflicted shenanigans, but am pretty sure that's the major issue atm.

(screenshot) that's more like it ...


EDIT: yep that fixed it. But it brought a few other things to my attention that should be put in ...

@daedalus in the meantime, If you're building your own, just move that lower brace to below "Pal = Palette.UfoBattle;" and that ought get TFTD-editing up and running.

[osd_daedalus]

@daedalus in the meantime, If you're building your own, just move that lower brace to below "Pal = Palette.UfoBattle;" and that ought get TFTD-editing up and running.

Ok, will do and put myself in /mode betatester == true

ADD: at a glance, there are some issues with various TFTD maps, mostly about invalid routes or MCD entries but I guess these are part of the other things you are looking at

[kevL]

tftd resources have issues, yes. Read: they're buggy even if they don't seem bugged while playing TFTD.

MapViewII simply points out any issues it recognizes but it's up to you to fix them if you want .... (make backups of all your resources first of course, or even set up a "scratch" directory for working on tilesets -- the CHM helpfile has things to say about stuff like that)

>I guess these are part of the other things you are looking at

nope i'm actually dealing with error messages about failing to load the CURSOR sprites (the targeter) and i want to change the Palette-variable to a Game-type variable (the one that caused the UFO vs TFTD bug). But if you notice behaviors of Mv2 that could be better, don't hesitate to mention them here

[Meridian]

ADD: at a glance, there are some issues with various TFTD maps, mostly about invalid routes or MCD entries but I guess these are part of the other things you are looking at

Buggy TFTD resources are usually fixed directly inside of OpenXcom, either via MCDPatches ruleset, or via consistency checks and removal of faulty data (e.g. invalid routes/nodes). Some fixes are also in the universal patch as a separate download.

[kevL]

2019 October 2

MapView
- show error if configuration files failed to create.
- handle any errors while loading the UFO/TFTD targeters (CURSOR.PCK+TAB) better.
- force-quit if a targeter-sprite does not get loaded.
- use an explicit Descriptor.GroupType variable instead of current palette to determine whether a tileset is for UFO or TFTD.

PckView
- if a PCK vs TAB mismatched count error occurs print the counts in the error that pops.
- if a sprite-overflow happens don't assume that a Bigobs sprite was trying to load into a terrain/unit spriteset (just show a generic error).
- reset titlebar text if a spriteset fails to load (that is, don't assume that a spriteset will load when setting the titlebar text).

XCom
- set the GroupType (aka. GameType: UFO/TFTD) in the Descriptor of each tileset.
- fixed a bad typo that caused all tilesets to use the UFO battle-palette; this made editing TFTD tilesets problematic at best, since it also affected which terrains were trying to be accessed. Fixed ...
- slight refactor of TileGroup loading (based on above fix).
- use a bitwise int to store spritesets' failure-to-instantiate status, instead of three booleans.
- add spriteset fail-state: Taboffset overflow condition.

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md


ps. Thanks osd_daedalus

[osd_daedalus]

ps. Thanks osd_daedalus

oh no, I have to thank you for your efforts on this project.
I wish to know enough coding to be much helpful...

Anyway, to return to the topic "Mapview on Linux":

even if my Monodevelop died for unknown reason, it is possible to compile as per these instructions:
https://medium.com/@hudsonmendes/build-net-4-5-on-linux-in-5-minutes-and-see-what-it-is-like-848ea45fc667

Which is, to be brief:

Code: [Select]

$ sudo apt-get install -y nuget mono-devel mono-xbuild
$ xbuild MapView.sln
(it builds in bin/Debug)

Then it works to me with mono Mapview.exe. Just remember to go immediately to Options and then set "Use Mono" to "true"


Of course, don't expect Mono to work like .NET... this can happen if you add a tile via Topview:

Code: [Select]

double free or corruption (fasttop)

=================================================================
Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

=================================================================
Native stacktrace:
=================================================================
0x5648b7509e15 - mono : (null)
0x5648b750a1ac - mono : (null)
0x5648b74b6741 - mono : (null)
0x5648b7509422 - mono : (null)
0x7f233b9d3890 - /lib/x86_64-linux-gnu/libpthread.so.0 : (null)
0x7f233accfe97 - /lib/x86_64-linux-gnu/libc.so.6 : gsignal
0x7f233acd1801 - /lib/x86_64-linux-gnu/libc.so.6 : abort
0x7f233ad1a897 - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x7f233ad2190a - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x7f233ad29004 - /lib/x86_64-linux-gnu/libc.so.6 : cfree
0x7f233699d016 - /usr/lib/libgdiplus.so.0 : GdipDeleteRegion
0x41779f63 - Unknown

=================================================================
Telemetry Dumper:
=================================================================
Pkilling 0x7f2328709700 from 0x7f2328508700
* Assertion: should not be reached at threads.c:6254
Pkilling 0x7f2337ea5700 from 0x7f2328508700
Pkilling 0x7f233c1d2780 from 0x7f2328508700
Pkilling 0x7f231bfff700 from 0x7f2328508700
Pkilling 0x7f232890a700 from 0x7f2328508700
Pkilling 0x7f231bdfe700 from 0x7f2328508700
Pkilling 0x7f2328307700 from 0x7f2328508700
Entering thread summarizer pause from 0x7f2328508700
Finished thread summarizer pause from 0x7f2328508700.

Waiting for dumping threads to resume

=================================================================
External Debugger Dump:
=================================================================
[New LWP 17606]
[New LWP 17607]
[New LWP 17967]
[New LWP 17968]
[New LWP 17969]
[New LWP 17970]
[New LWP 17971]
[New LWP 17972]
Mono support loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: File o directory non esistente.
  Id   Target Id         Frame
* 1    Thread 0x7f233c1d2780 (LWP 17605) "mono" __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
  2    Thread 0x7f233a3ff700 (LWP 17606) "SGen worker" 0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b7aea0a8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  3    Thread 0x7f2337ea5700 (LWP 17607) "Finalizer" 0x00007f233b9d16d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x5648b7adb2c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  4    Thread 0x7f232890a700 (LWP 17967) "Timer-Scheduler" 0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b8b1d5e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  5    Thread 0x7f2328709700 (LWP 17968) "Timer-Scheduler" 0x00007f233b9ceed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f2328708bc0, expected=0, futex_word=0x5648b7aeab68) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
  6    Thread 0x7f2328508700 (LWP 17969) "Thread Pool Wor" 0x00007f233b9d323a in __waitpid (pid=17978, stat_loc=0x7f2328505fd4, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  7    Thread 0x7f2328307700 (LWP 17970) "Thread Pool Wor" 0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f2328306d50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  8    Thread 0x7f231bfff700 (LWP 17971) "Thread Pool Wor" 0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bffed50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  9    Thread 0x7f231bdfe700 (LWP 17972) "Thread Pool Wor" 0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bdfdd50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205

Thread 9 (Thread 0x7f231bdfe700 (LWP 17972)):
#0  0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bdfdd50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d18c2 in do_futex_wait (sem=sem@entry=0x5648b7adbc08, abstime=abstime@entry=0x7f231bdfdd50) at sem_waitcommon.c:111
#2  0x00007f233b9d19d3 in __new_sem_wait_slow (sem=0x5648b7adbc08, abstime=0x7f231bdfdd50) at sem_waitcommon.c:181
#3  0x00005648b770b705 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f231bdfe700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7f231bfff700 (LWP 17971)):
#0  0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bffed50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d18c2 in do_futex_wait (sem=sem@entry=0x5648b7adbc08, abstime=abstime@entry=0x7f231bffed50) at sem_waitcommon.c:111
#2  0x00007f233b9d19d3 in __new_sem_wait_slow (sem=0x5648b7adbc08, abstime=0x7f231bffed50) at sem_waitcommon.c:181
#3  0x00005648b770b705 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f231bfff700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7f2328307700 (LWP 17970)):
#0  0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f2328306d50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d18c2 in do_futex_wait (sem=sem@entry=0x5648b7adbc08, abstime=abstime@entry=0x7f2328306d50) at sem_waitcommon.c:111
#2  0x00007f233b9d19d3 in __new_sem_wait_slow (sem=0x5648b7adbc08, abstime=0x7f2328306d50) at sem_waitcommon.c:181
#3  0x00005648b770b705 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f2328307700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7f2328508700 (LWP 17969)):
#0  0x00007f233b9d323a in __waitpid (pid=17978, stat_loc=0x7f2328505fd4, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x00005648b750a125 in  ()
#2  0x00005648b750a1ac in  ()
#3  0x00005648b74b6741 in  ()
#4  0x00005648b7509422 in  ()
#5  0x00007f233b9d3890 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007f233accfe97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7  0x00007f233acd1801 in __GI_abort () at abort.c:79
#8  0x00007f233ad1a897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f233ae47b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#9  0x00007f233ad2190a in malloc_printerr (str=str@entry=0x7f233ae49828 "double free or corruption (fasttop)") at malloc.c:5350
#10 0x00007f233ad29004 in _int_free (have_lock=0, p=0x5648b9adbdf0, av=0x7f233b07cc40 <main_arena>) at malloc.c:4230
#11 0x00007f233ad29004 in __GI___libc_free (mem=0x5648b9adbe00) at malloc.c:3124
#12 0x00007f233699d016 in GdipDeleteRegion () at /usr/lib/libgdiplus.so.0
#13 0x0000000041779f63 in  ()
#14 0x00007f2328a92070 in  ()
#15 0x00007f2328d16830 in  ()
#16 0x0000000000000000 in  ()

Thread 5 (Thread 0x7f2328709700 (LWP 17968)):
#0  0x00007f233b9ceed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f2328708bc0, expected=0, futex_word=0x5648b7aeab68) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  0x00007f233b9ceed9 in __pthread_cond_wait_common (abstime=0x7f2328708c60, mutex=0x5648b7aeab80, cond=0x5648b7aeab40) at pthread_cond_wait.c:533
#2  0x00007f233b9ceed9 in __pthread_cond_timedwait (cond=0x5648b7aeab40, mutex=0x5648b7aeab80, abstime=0x7f2328708c60) at pthread_cond_wait.c:667
#3  0x00005648b776304b in  ()
#4  0x00005648b776dfb8 in  ()
#5  0x00005648b770ae52 in  ()
#6  0x00005648b76a9ceb in  ()
#7  0x00007f233b9c86db in start_thread (arg=0x7f2328709700) at pthread_create.c:463
#8  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7f232890a700 (LWP 17967)):
#0  0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b8b1d5e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x00007f233b9ce9f3 in __pthread_cond_wait_common (abstime=0x0, mutex=0x5648b8b1d598, cond=0x5648b8b1d5c0) at pthread_cond_wait.c:502
#2  0x00007f233b9ce9f3 in __pthread_cond_wait (cond=0x5648b8b1d5c0, mutex=0x5648b8b1d598) at pthread_cond_wait.c:655
#3  0x00005648b77630ad in  ()
#4  0x00005648b76c070c in  ()
#5  0x00005648b76c1d5f in  ()
#6  0x00005648b76c2450 in  ()
#7  0x00005648b76a671d in  ()
#8  0x00005648b763a440 in  ()
#9  0x00000000418b83af in  ()
#10 0x00007f233a7504e0 in  ()
#11 0x00007f233a7506b0 in  ()
#12 0x00007f233a750410 in  ()
#13 0x0000000000000000 in  ()

Thread 3 (Thread 0x7f2337ea5700 (LWP 17607)):
#0  0x00007f233b9d16d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x5648b7adb2c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d16d6 in do_futex_wait (sem=sem@entry=0x5648b7adb2c0, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007f233b9d17c8 in __new_sem_wait_slow (sem=0x5648b7adb2c0, abstime=0x0) at sem_waitcommon.c:181
#3  0x00005648b76f5858 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f2337ea5700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f233a3ff700 (LWP 17606)):
#0  0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b7aea0a8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x00007f233b9ce9f3 in __pthread_cond_wait_common (abstime=0x0, mutex=0x5648b7aea0c0, cond=0x5648b7aea080) at pthread_cond_wait.c:502
#2  0x00007f233b9ce9f3 in __pthread_cond_wait (cond=0x5648b7aea080, mutex=0x5648b7aea0c0) at pthread_cond_wait.c:655
#3  0x00005648b775335a in  ()
#4  0x00007f233b9c86db in start_thread (arg=0x7f233a3ff700) at pthread_create.c:463
#5  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f233c1d2780 (LWP 17605)):
#0  0x00007f233adc16ac in __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x00007f233ad2b352 in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3407
#2  0x00005648b777870b in monoeg_g_calloc ()
#3  0x00005648b77757a5 in monoeg_g_hash_table_new ()
#4  0x00005648b75f44c7 in  ()
#5  0x00005648b75f5230 in mono_class_load_from_name ()
#6  0x00005648b7610287 in  ()
#7  0x00005648b761041d in mono_exception_from_name_domain ()
#8  0x00005648b74b8113 in  ()
#9  0x00005648b7503662 in  ()
#10 0x00007f233ad253c1 in _int_malloc (av=0x7f233b07cc40 <main_arena>, bytes=0) at malloc.c:3612
#11 0xffffffffffff00ff in  ()
#12 0xffffffffffffffff in  ()
#13 0x0000000000000000 in  ()

=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x7f233accfe97):0x7f233accfe87  d2 4c 89 ce bf 02 00 00 00 b8 0e 00 00 00 0f 05  .L..............
0x7f233accfe97  48 8b 8c 24 08 01 00 00 64 48 33 0c 25 28 00 00  H..$....dH3.%(..
0x7f233accfea7  00 44 89 c0 75 1f 48 81 c4 18 01 00 00 c3 0f 1f  .D..u.H.........
0x7f233accfeb7  00 48 8b 15 a9 bf 3a 00 f7 d8 41 b8 ff ff ff ff  .H....:...A.....

=================================================================
Managed Stacktrace:
=================================================================
  at <unknown> <0xffffffff>
  at System.Drawing.GDIPlus:GdipDeleteRegion <0x000a2>
  at System.Drawing.Region:DisposeHandle <0x0004b>
  at System.Drawing.Region:Dispose <0x0002b>
  at System.Drawing.Region:Dispose <0x00073>
  at DoubleBuffer:Invalidate <0x0003b>
  at System.Windows.Forms.Control:InvalidateBackBuffer <0x00043>
  at System.Windows.Forms.Control:OnInvalidated <0x000cb>
  at System.Windows.Forms.Control:Invalidate <0x004da>
  at System.Windows.Forms.Control:Invalidate <0x00047>
  at MapView.Forms.MainView.MainViewOverlay:InvalidateObservers <0x0004b>
  at MapView.Forms.MainView.MainViewOverlay:FillSelectedQuads <0x0024b>
  at MapView.Forms.MainView.MainViewOverlay:FillSelectedQuads <0x00073>
  at MapView.Forms.Observers.QuadrantPanel:OnClicksElapsed <0x00063>
  at System.Timers.Timer:MyTimerCallback <0x0017a>
  at Scheduler:TimerCB <0x00133>

Just for the records... as I set up a VM for openxcom development

[osd_daedalus]

Just for the records... as I set up a VM for openxcom development

Erm... looks like not really true. Can you try to do this?

- open MapView
- load UFO_110
- go in TileView, select a tile
- go in Topview, rightclick somewhere to add that tile

In VSCommunity I got "unhandled exception" on TileView.cs, line 675. Check also my screenshot
Roughly translating from Italian according to the screenshot, it is saying Cross-thread operation invalid: the control access 'tcTileTypes' was executed from a thread different from the one which created it

Looks like I blamed Mono too early 

[kevL]

i just downloaded w/ fresh install, and unfortunately can't reproduce ...

notes:
- Mv2 is not multi-threaded
- my OS is Windows7 Pro SP1 64-bit
- right-clicks on TopView use a special algorithm to determine if it's a single or double click: a click is registered in mapview but delayed for the duration of the operating system's SystemInformation.DoubleClickTime (this design prevents the app from first doing a single right-click operation [place tilepart] followed by a double right-click operation [clear tilepart] in succession when double right-clicking, and you can notice this even on a single right-click -- there's a slight delay, which ought be the duration of your system's DoubleClickTime)

My guess at present is that a Windows VM doesn't handle that well,


i guess I could take it out (it's merely cosmetic), or put in a user-option (like "UseMono") to flag a bypass ....




EDIT: a workaround could/should be to use keyboard shortcuts instead of RMB clicks.

a) to place a part, select a tile as usual, select a tilepart as usual, and press [Enter] with TopView having focus. (Be careful to have the correct quadrant-type selected, since the part will be placed in the currently selected quad-panel.)
b) to clear a part, select a tile as usual, select a quadrant as usual, and press [Shift+Delete] with TopView having focus. (Note that pressing [Delete] clears all parts from the selected tile, while [Shift+Delete] clears only the selected quadrant's part from the tile.)

"quadrant" means "tilepart typeslot" but its easier to write "quadrant" or just "quad" instead ... y'll get the hang of it

[osd_daedalus]

So...

I booted to Windows 10 (native), installed VS Community, made same steps, and got same exception.

The issue won't happen, though, if I run the program as Release, rather than Debug.

In Debug, using ENTER instead of RMB click won't throw exception and works faster.

So...
- the issue is confirmed, and not an issue with my VM.
- Though, the program still goes on, the issue just manifests itself as a delay (when running Release)
- looks like then related to mouse button detection algorithm as you explained.

i guess I could take it out (it's merely cosmetic), or put in a user-option (like "UseMono") to flag a bypass ....

You decide

[kevL]

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.

- 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)

[osd_daedalus]

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 
Moreover, it made Mono builds much stable.

[osd_daedalus]

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