Error while compiling MapWinGIS component in Delphi 10.3 - delphi-10.3-rio

I intend to use the MapWinGis component in Delphi 10.3
There are a number of errors when compiling this component
Has anyone used this component to guide me?

I had the same problem. As fpiette told you, you should change 'result' to 'AResult' in all functions producing this error.
function TShapefile.SelectShapes(const BoundBox: IExtents; Tolerance: Double; SelectMode: SelectMode; var AResult: OleVariant): WordBool;
begin
Result := DefaultInterface.SelectShapes(BoundBox, Tolerance, SelectMode, AResult);
end
You must also change it in the interface section of MapWinGIS_TLB.pas.
Unfortunately that's not all. Compilation and linking is now possible but I got errors to register the classes TImage, TShape, TPoint, TTable, TLabel, TChart, TGrid, TField because Delphi already uses these names for classes.
So, you must rename these classes (TImage to TMWImage, etc.) in MapWinGIS_TLB.pas.
Afterwards registration of these classes is working and the component TMap should be shown in the ActiveX tab or the tab you defined.

Related

How do I get system default checkbox BITMAP in VS2015?

I want to get the system's default checkbox for to display it in an owner-drawn MFC menu.
I have read this question, but that did not answer my question.
I want to implement this line:
hbmpCheckboxes = LoadBitmap((HINSTANCE) NULL,
(LPTSTR) OBM_CHECKBOXES);
which I got from MSDN, section
Simulating Check Boxes in a Menu
I get this error: Error C2065 'OBM_CHECKBOXES': undeclared identifier
If I define it myself: #define OBM_CHECKBOXES 32759, and I run the code, then LoadBitmap returns a handle. In VS2015 I see this: hbmpCheckboxes 0xc305143c {unused=??? }, so to me it seems an invalid bitmaphandle is returned. I think there is more missing than just the OBM_CHECKBOXES define, but I can't figure out what.
Is there a file I should include?
Is there a DLL which I need to link
against?
Is there a project setting I should set?
Or...?
Have a look at this topic.
You want to use CBitmap::LoadOEMBitmap and note the comment at the bottom:
Note that the constant OEMRESOURCE must be defined before including WINDOWS.H in order to use any of the OBM_ constants.

How to work around array of components with fixed size error?

I have a class with a port of dimensions [x,y] which is connected to another class having a matching port. Now I want to provide value to these variables [x,y] through external function call in which I basically read a .xml file and obtain values for x and y. But Dymola gives an error for this since during compilation it comes out as a non fixed size array.
Screenshot of error is attached.
The array sizes are structural parameters and they usually cannot depend on external function calls because they should be known at compile time. This is however supported in for example OpenModelica where a dll of the external function is built and called and the results are fetched during model compilation.
The only way to support this in all tools is to generate the model using an external tool which reads the xml and changes the .mo file with the values read.
You could probably have something like Parameters.mo:
package Parameters
constant Integer nTube = <EXTERN_NTUBE>;
constant Integer nSeg = <EXTERN_NSEG>;
end Parameters;
and your external tool will read the XML and bind and in Parameters.mo which you can then use in your models via Parameters.nTube and Parameters.nSeg. Maybe it would be good to give some defaults so that it works to use this file directly:
package Parameters
constant Integer nTube = 1;
constant Integer nSeg = 2;
end Parameters;
and then your external tool will replace 1 and 2 with the needed values before compilation.
This should be improved in Dymola 2017 (without the need for modifying the Modelica code). In earlier versions of Dymola it should work if the you translate the C-functions called to compute nTube and nSeg.
If that does not help your complete code would be needed to analyze the problem.

How to define a VHDL component and package?

Below I do have following two VHDL files. The file x.vhd with a component x which needs to be referenced (included) in the file top.vhd as a package.
-- x.vhd
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
package x_pkg is
component my_x
port(clk_clk : in std_logic := '0';
reset_reset_n : in std_logic := '0';
end component my_x;
end package x_pkg;
-----------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
entity x is
port (
clk_clk : in std_logic := '0'; -- clk.clk
reset_reset_n : in std_logic := '0'; -- reset.reset_n
);
end entity x;
architecture rtl of x is
This package needs to be referenced in following top-file:
-- top.vhd
library ieee;
use ieee.std_logic_1164.all;
library altera;
use altera.altera_syn_attributes.all;
use work.x_pkg.all;
entity EyeTracker_Top is
port
(
Nios_Clk : in std_logic;
Nios_Reset_n : in std_logic;
);
end EyeTracker_Top;
architecture struct of EyeTracker_Top is
begin
M1 : my_x port map(Nios_Clk, Nios_Reset_n); -- Here I get the error message!
After compiling, it get following error message:
***Error (12006): Node instance "M1" instantiates undefined entity "my_x"
What is the problem here? I guess there is something wrong with the package reference...
Thanks!
You are instantiating a component my_x. A component is just a declaration, a kind of empty shell. Every component instantiation must at some point be bound to an actual entity/architecture pair. This binding must be done with an explicit configuration. There are several ways to do this. One is to add:
for all: my_x use work.x(rtl);
in the declaration area of your architecture (between architecture and begin). Of course, the entity x and its architecture rtl must be compiled in the library you use as work before you can elaborate your top level.
The error message you got is difficult to understand because your tool tries to apply a default configuration strategy based on names: for unbound instances of components it searches an entity with the same name as the component. Because it found none, it complains about a missing entity while it is a component binding problem, that is, a missing configuration. A better tool would tell you that the M1 instance of component my_x is not bound.
A last note: if all this component stuff is too complicated for your needs, just get rid of it and directly instantiate your entity:
M1: entity work.x(rtl) port map(Nios_Clk, Nios_Reset_n);
and you will need no component declaration and no configuration.
There are basically two approaches:
top-down design with components instantiations and configurations,
bottom-up design with entity instantiations, no components and no configurations.
Understanding the differences between the two, their pros and cons is not easy. And there, a good VHDL book is probably better than questions and answers on stackoverflow.

error in declaring higher-order functions in XPath 3.0: must declare return type?

Following #DimitreNovatchev's article Programming in XPath 3.0, and using BaseX GUI as the test environment, I tried some of the examples that define functions that accept functions as parameters. E.g. with
let $compose :=
function($f as function(), $g as function())
(The rest of the code isn't relevant to this error, but you can see it as the third example under Function Composition.)
I get this error from BaseX:
Error:
Stopped at 43-compose.xpath, 2/39:
[XPST0003] Expecting 'as', found ','.
The point where the error was detected was on the second line, just before the comma. Apparently, the processor expects the $f parameter declaration to say not just that $f should be a function, but also the return value of the function.
I don't know whether it's right for BaseX to expect that or not. Presumably, Dimitre's examples tested successfully before he made that presentation at Balisage. Maybe something changed in the XPath 3.0 spec between that article and when BaseX was released?
OK, found the answer. I got an evaluation key for Saxon EE, so I was able to try another processor. For future reference, this was the command line:
C:\Program Files\Saxon>java -cp saxon9ee.jar net.sf.saxon.Query -s:"input.xml" -
q:"ex5.xpath" -qversion:3.0
Note that -qversion:3.0 is currently required in order to get any 3.0 functionality.
Saxon throws an error at the same point, but gives a helpful suggestion on how to fix it:
Error on line 2 column 39 of ex5.xpath:
XPST0003 XQuery syntax error near #... function($f as function(), $#:
function() is no longer allowed for a general function type: must be function(*)
I changed function() to function(*) wherever a general function type was wanted, and the errors went away, both in BaseX and in Saxon.
So apparently BaseX was correct (but Saxon's error message was more helpful, as is often the case!). Sounds like something did change in the spec recently. I haven't been able to figure out what the relevant change was, from the change log. But regardless of what changed, the spec currently says that a FunctionTest must have either a * within the parentheses, or an as after them. (This applies to declarations of parameters that are functions, but does not apply to inline functions themselves.)

Typescript 0.9.5 won't compile .d.ts

When I copy my AngularJS code from an existing project into a new project, typescript compiler reports an error for the new project as below:
Error 2 Build: Could not find symbol 'bool'.Scripts\AngularTS\ng\route.d.ts Line 8 Column 26
Yes, I understand that the route.d.ts is old that still uses 'bool' which should be 'boolean'.
But the strange thing is: my existing project does not report the error. (Same computer, same typescript compiler 0.9.5).
I tried to edit route.d.ts (added random chars) in my exisiting project, still no error was reported. It seems that typescript compiler won't compile it!
So my question is why typescript behaved so differently in the two situations?
======== Updated ========
The latest finding is: when there is another error, this error will be reported.
If there is no other errors, then it won't be.
So strange!
The bool vs boolean error is actually really a warning. TypeScript will still happily compile your code. You can even 'get away with it' in later versions of the compiler, although the type won't be boolean it will be any.
So it is worth fixing as you will lose proper checking if you don't update to boolean.
var x: bool = true;
if (x === true) {
alert("Isn't it though");
}
See this on the TypeScript playground.

Resources