WINRT XAML System.Void Compile Error in - windows-store-apps

after a little code change inside a Store App I ran into a compilation error:
-> System.Void cannot be used from C# -- use typeof(void) to get the void type object.
Problem is: this comes from a generated file: XamlTypeInfo.g.cs.
case "System.Void"
userType= new ... ,typeof(global::System.Void), ...
...
Rolling back the changes did not help, as deleting bin & obj, restarting, etc.
Is the actual System.Void case entry maybe an indicator that something within a XAML file could not be recognized by the code generator? Is there an System.Void entry in a working XamlTypeInfo.g.cs?
--- ADDITION ---
I can now produce the compile error when changing specific lines. I have a custom control deriving from ItemsControl. I define a regular DP which works fine. I am also providing AttachedProperties for Template, TemplateSelector and Style. Think of a Textbox that gets an Label via an AttachedProperty and its not just a string but like HeaderedControls you can define a Template etc. for the Lable.
The Problem is related to the Get/Set Methods for the AttachedProp. When I either change the Getter return type to DataTemplate or I comment out the Setter fully then the compile error comes:
public static DataTemplate GetLabelTEmplate(UIElement element)
{
return (DataTemplate)element.GetValue(LabelTemplateProperty;
}
public static void SetLabelTemplate(UIElement element, object value)
{
element.SetValue(LabelTemplateProperty, value);
}
Any ideas would be highly appreciated.
Best regards
Gope

After filing a bug complaint with microsoft they pointed me to the problem: The setter's value cannot be of type object. This information is needed for the XamlTypeInfo generation so when I changed object to DataTemplate it compiled.
Although I haven't tried it yet, I believe object is fine for plain WPF, but for Win 8 Store apps this does result in an compilation Error. Funny stuff... :)

Related

Unexpected behaviour from Gson

I developed a small application that stores data coming from a device: I chose to store data in JSON format, and the serialization/deserialization of the data works just fine, even if it involves some custom types created by me...but only I work in the IDE (Eclipse, for that matter).
When I export a runnable JAR file though, the deserialization of the data encounters some kind of problem, because the software always throws this exception:
Caused by: java.lang.UnsupportedOperationException: Cannot allocate class LocalDateTime
at com.google.gson.internal.UnsafeAllocator$4.newInstance(UnsafeAllocator.java:104)
at com.google.gson.internal.ConstructorConstructor$14.construct(ConstructorConstructor.java:225)
... 88 common frames omitted
I thought I'd encounter problems with custom types, not a built-in one. At this point, I discovered two things:
if I use a full JRE 9 to run the JAR file, the exception is not thrown: I double checked the modules included in the custom JRE I created with Jlink.exe, and everything is included correctly. I still want to use a smaller JRE, so I did not investigate further yet (I guess this explains why in the IDE it works perfectly)
I added a custom deserializer to the Gson object (see below), with which I simply manually converted the JSON string into a valid data, and that avoided the exception on the LocalDateTime class...but the exception reappeared simply on another class, this time a custom-made one.
At this point, I guess I can simply add a deserializer for each data type that causes problem, but I'm wondering why the issue won't happen with a full JRE, and why a smaller JRE causes this, even if all the modules required are included. Maybe it's worth mentioning also that I added no custom serializer to the Gson object that saves the data, it is all serialized as per Gson default.
LocalDateTime deserializer:
#Override
public LocalDateTime deserialize(JsonElement json, java.lang.reflect.Type type,
JsonDeserializationContext jsonDeserializationContext) throws JsonParseException {
JsonObject joDate = json.getAsJsonObject().get("date").getAsJsonObject();
JsonObject joTime = json.getAsJsonObject().get("time").getAsJsonObject();
//JSON example: {"date":{"year":2019,"month":1,"day":9},"time":{"hour":6,"minute":14,"second":1,"nano":0}
return LocalDateTime.of(joDate.get("year").getAsInt(),
joDate.get("month").getAsInt(),
joDate.get("day").getAsInt(),
joTime.get("hour").getAsInt(),
joTime.get("minute").getAsInt(),
joTime.get("second").getAsInt(),
joTime.get("nano").getAsInt());
}
}
Jdeps.deps modules list:
com.google.gson
java.base
javafx.base
javafx.controls
javafx.fxml
javafx.graphics
org.slf4j
After the answer I received, I opened an issue here.
TL;DR
You need a runtime image (e.g. full JDK or something built with jlink) that includes the module jdk.unsupported.
Full Answer
GSON wants to create instances of classes it deserializes without calling any constructors (so nothing gets initialized without GSON saying so). This can't normally be done, but sun.misc.Unsafe offers a way to do this with the method allocateInstance. To that end, GSON needs an instance of sun.misc.Unsafe. The topmost frame in the call stack is from UnsafeAllocator, which uses common trickery to get Unsafe.
The problem is, sun.misc.Unsafe is in module jdk.unsupported, which is present in a full JDK but you won't usually find in runtime images.
When creating your runtime image with jlink, make sure to include the option --add-modules jdk.unsupported and you should be good to go.
Arguably, GSON should declare an optional dependency on jdk.unsupported with requires static.
I have faced the same issue when packing compose a desktop application.
update build.gradle file, add an unsupported module.
compose.desktop {
application {
mainClass = "MainKt"
nativeDistributions {
targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
packageName = "admin"
packageVersion = "1.0.0"
modules("java.sql")
modules("jdk.unsupported")
}
}
}

MS Access: Property defined with 'Form' return type in a interface gives user-defined type not defined compilation error

Looking for help writing an interface that has a property (or function) that returns an object typed as a "Form" (e.g. Access.Form as the return type).
Problem description:
The following simple example code returns a "User-defined type not defined" error if I attempt to compile the project.
I_TestInterface:
Public Property Get MyForm() as Form
End Property
cls_TestClass:
Implements I_TestInterface
Public Property Get I_TestInterface_MyForm() as Form
End Property
This is the only code/objects in a otherwise blank Access-2016 database and asking VBA to 'compile' produces a "User-defined type not defined" error. No lines are highlighted, it simply won't compile. Same occurs if replace 'Form' by "Access.Form"
My usecase is writing classes that wrap/hold a reference to a form internally - sometimes it is easiest to provide a reference to the underlying form so that consuming code can get at form properties without coding them all into the wrapper class.
Steps taken:
Lots of searches on 'user-defined type not defined' errors, in almost all cases this is due to a missing reference. Does not seem applicable since can create a standard module and happy to compile if write a function with a Form return type there. (*)
There was one previous SO thread on similar 'ambiguous' 'user-defined type not defined' error but I can't find it again and it wasn't specific to the 'Form' type in MS-Access
Have a clumsy workaround of providing property that returns an Object type that consuming code just has to cast to a Form (e.g. public property get MyFormAsObjectThatCanBeCastToForm() as Object).
(*). Possible clue? - if I just change the return types to object, the code still won't compile. I need to exit and use the 'de-compile' start up switch when relaunch Access. Then the above code with Object used as a return type is happily compiled.
Question / request:
Before I start re-installing Office, can others reproduce this?
Has anyone experienced this before? Developed a solution?
Thanks
PAHTDC

ILSpy (a.k.a. .NET Reflector) shows a method as just calling itself, why?

When passing anonymous types to an HtmlHelper method like TextBox, you'll get binding errors (because anonymous type members have internal access only), unless you use a RouteDataDictionary to extract the members.
When I saw that the (HtmlHelper extension) InputExtensions.TextBox method accepted anonymous types, I knew it had to be doing some conversion internally or it would fail with the same error.
Sure enough, it calls HtmlHelper.AnonymousObjectToHtmlAttributes method, whose documentation tries to play down the issue by not mentioning it, instead suggesting it's just replacing underscores with dashes to ensure valid attribute names are used. Sure. Anyway...
I wanted to see exactly what that conversion looks like, but when I inspect HtmlHelper's static method with that name in ILSpy, the method appears to just call itself. What is going on here?
public static RouteValueDictionary AnonymousObjectToHtmlAttributes(object htmlAttributes)
{
return HtmlHelper.AnonymousObjectToHtmlAttributes(htmlAttributes);
}
The method AnonymousObjectToHtmlAttributes from System.Web.MVC.HtmlHelper is calling a method with the same name but from System.Web.WebPages.Html.HtmlHelper.
The ILSpy is not explicitly about that. I needed to hover the class to show from where it was coming:
I asked a similar question that was anwered here.

RazorEngine extension method fails with RuntimeBinderException after upgrade to Razor 2/ RE 3.2

I have a RazorEngine project that fails following an upgrade to Razor 2.0 and RazorEngine 3.2.0
This worked fine in the previous Razor 1.0 based version of RazorEngine (3.0.8).
I have an instance (myInstance) of a class (MyClass) and and extension method:
namespace MyCompany.Extensions
{
public static class MyClassExtensions
{
public static string ExtensionMethod(this MyClass thing)
{
// do stuff
}
}
}
I want to call this in a RazorEngine view (simplified example, there are loads of these methods, and all fail the same way):
#using MyCompany.Extensions
#using MyCompany
#{
var myInstance = new MyClass(Model, ...);
}
Some text #myInstance.ExtensionMethod() some more text
This is in a text file that's compiled by RazorEngine:
string parsedResult = RE::Razor.Parse(fileContent, myModel, "testfile.txt");
The problem is that this line (which used to work) throws a RuntimeBinderException:
'MyCompany.MyClass' does not contain a definition for 'ExtensionMethod'
Note that if I change the text file to:
Some text #MyClassExtensions.ExtensionMethod(myInstance) some more text
It works fine, so I think it must find the extension method's namespace.
My first thought was that it must be considering the passed model as a dynamic (and hence anything derived from it as dynamic too), but it knows the expected type in the RuntimeBinderException. As the exception is run-time I think it must be failing to identify the extension method while the template is compiled, but why would that have changed?
I'm not sure what's changed between 3.0.8 and 3.2.0, or why this is broken. Is there something I need to add so that the extension method can be found while the template is compiled?
This is a bug in RazorEngine: the Razor.Compile works on TemplateBase<dynamic> (so Model and everything derived from it is dynamic too) and that means that no extension methods undergo the 'compiler-magic' to convert them to the static calls. Then Razor.Run passes the Model as the correct type, but the extension method syntax is called as an instance method.
There will probably be a fix for this soon (the bug's only a few days old and this is a corner case), but in the meantime I have a workaround: explicitly type the Model in the Razor template
#using MyCompany.Extensions
#using MyCompany
#{
ExpectedModelClass strongTypeModel = Model as ExpectedModelClass;
MyClass myInstance = new MyClass(strongTypeModel , ...);
}
Some text #myInstance.ExtensionMethod() some more text
This now works, because even though Model is still dynamic at compile-time that doesn't spread to myInstance any more.
It's not ideal, and everywhere I used Model now has to be strongTypeModel, but that's a much simpler substitution.

passing custom events between modules through parent application

I have created a custom event that I want to use to pass a string between two modules. The event looks like this:
package com.mypackage.events
{
import flash.events.Event;
public class ThumbDeleteEvent extends Event
{
public static const THUMBS_DELETED:String = "thumbsDeleted";
public var files:String;
public function ThumbDeleteEvent(type:String, files:String)
{
super(type);
this.files = files;
}
// Override the inherited clone() method.
override public function clone():Event {
return new ThumbDeleteEvent(type, files);
}
}
}
In one module I dispatch the event like so:
parentApplication.dispatchEvent(new ThumbDeleteEvent("parentApplication.thumbsDeleted", files));
and in another module I listen for the event like so:
public function init():void {
parentApplication.addEventListener("parentApplication.thumbsDeleted", onThumbsDelete);
}
if I use ThumbsDeleteEvent as the type passed in to the listener function like this:
public function onThumbsDelete(evt:ThumbDeleteEvent):void{
trace("thumb delete event for thumbs: "+evt.files);
}
I get the following error:
TypeError: Error #1034: Type Coercion failed: cannot convert com.mypackage.events::ThumbDeleteEvent#26748a31 to com.mypackage.events.ThumbDeleteEvent.
if I just use Event as the type passed in to the listener function like this:
public function onThumbsDelete(evt:ThumbDeleteEvent):void{
if(evt is ThumbDeleteEvent){
trace("thumb delete event for thumbs: "+(evt as ThumbDeleteEvent).files);
}else{
var type:XML = describeType(evt);
trace(type.toXMLString());
}
}
It works but does not think it is a ThumbDeleteEvent type class (it hits the else statement) the xml output of describe type says its type is:
type name="com.mypackage.events::ThumbDeleteEvent"
What is going on here? If I put a breakpoint in the debugger it says the event is a ThumbDeleteEvent and I can see the files parameter and its right???
The issue here is that one swf has their definition of that class, and then the other swf has its own version of that exact same class. When trying to cast between them flash does a bytecode-check to see if the definitions are the same, and if you ever changed something in that as file without updating both with the exact same info you will run into this issue. That is, compile both swf-files, then change a space in the as-file, and compile only one swf file.
Urgh it's coming back to me, all those issues with shared code between different modules. I always just slug my way through these errors until I get it to work and can never really remember what it is since it can be so many issues.
Make sure both compiled swf-files have up-to-date-versions of the file.
Make sure both swf-files have same linkage-nesting to the code-file.
If that doesn't work [can't really remember since this issue is kind of like solve-once and copy to every other project].
See in which order things are added to ApplicationDomain and make sure nothing else has their own out-of-date-version of it through something imported in flash library
Move shared code into seperate code library linked in with "dynamic binding"
Try with sharing the Interface instead
Change how assets are loaded into the ApplicationDomain
Hopefully someone has more knowledge of this issue and can tell exactly what steps to use, but this is at least a starting point... I might have more time to research this and write a post about it sometime in the future later today.
Edit:
from another SO-thread Custom AS3 Class not Updating
This is the age old problem of what ultimately boils down to is the Verify Error. It happens when you embed "Class A" in one or more applications, modules, swfs, etc. Ultimately every output swf that uses "Class A" must be recompiled when "Class A" is changed. Otherwise you end up with a situation where 1 module has the newer implementation but others don't. This problem is compounded by the fact that the application domain is defined as a "first in wins" when it encounters a Class of the same name / package - meaning if the old one is referenced first, the newer one loaded later gets ignored.
The more permanent solution is to use class promotion to an RSL that ultimately allows the RSL to control the actual "Class A" reference in which it also implements an "IClassAImpl" interface that all modules use. This allows the compiler to cross link the reference with a signature it knows about without actually embedding the actual class itself.