it is osm
No offense, but that exactly tells me shite (yes, i know it stands for open street map).
So after picking my brain on why google was unable to find the named units or components used in the test-project, i managed to find something on the forums that linked me to some google-code.
I tried removing cthreads from the Uses, but it epic fails
It epically works for me so we must be doing something different (mind you, i can compile the project. not saying explicitly the test project actually works).
Also your reaction seem to imply that removing cthreads is giving you the 'epic failure' while that is at the least misleading as the produced errors are originating from issues that are completely unrelated to cthreads.
So, after i was forced to install packages rgbgraphics and synapse the problems with compiling the test project became more clear:
- you need to add mapviewer dependency using project inspector
- do not use cthreads when compiling for windows. I already gave the solution for that.
- unit mvMapOperator does not exist so i commented that unit out wherever it was used.
- Type TTileId could not be found as unit mvmapprovider (which declares that type) was not in uses clause.
- Compiler complained about method TMapViewerEngine.Redraw inside unit mvengine about int64 (x and y variables) not being ordinary type, so i changed those to be of type integer instead.
I was able to make that above list based on what the compiler returned for me when attempting to compile/install things.
Strange that you are not able to provide a single error message and instead being persistent about cthreads/bindings
Compiler generated errors do not fall into the category "epic failure" but in the category "look, i the compiler am confused because something was done wrong, please help me".