kayrk
Posts: 41
Joined: 07 May 2014, 19:41

Re: [Unity] v1.2 Preview

02 Oct 2014, 19:13

Sounds good thanks! Every other issue I have has been solved by this new update great work.
 
User avatar
jsantos
Site Admin
Topic Author
Posts: 3905
Joined: 20 Jan 2012, 17:18
Contact:

Re: [Unity] v1.2 Preview

03 Oct 2014, 11:26

We have uploaded a new version fixing those issues.
 
kayrk
Posts: 41
Joined: 07 May 2014, 19:41

Re: [Unity] v1.2 Preview

03 Oct 2014, 18:08

I had one quick question you noted we no longer needed to have a .font file for fonts. I'm having a hard time using a different FontFamily then the default it comes with I tried doing like FontFamily="../HUD/Fonts/fontname.ttf" I'm guessing this is incorrect way to do it since my xaml wont build with this. Any help is appreciated.
 
User avatar
jsantos
Site Admin
Topic Author
Posts: 3905
Joined: 20 Jan 2012, 17:18
Contact:

Re: [Unity] v1.2 Preview

03 Oct 2014, 18:14

I had one quick question you noted we no longer needed to have a .font file for fonts. I'm having a hard time using a different FontFamily then the default it comes with I tried doing like FontFamily="../HUD/Fonts/fontname.ttf" I'm guessing this is incorrect way to do it since my xaml wont build with this. Any help is appreciated.
Effectively, .font files are no longer needed. But the way you use fonts is the same as in v1.1. You must set the property FontFamily to the desired family. For example:
FontFamily="Fonts/#Roboto"
This will use a .ttf file in the Font folder that includes the Roboto family.
 
kayrk
Posts: 41
Joined: 07 May 2014, 19:41

Re: [Unity] v1.2 Preview

03 Oct 2014, 20:29

I had one quick question you noted we no longer needed to have a .font file for fonts. I'm having a hard time using a different FontFamily then the default it comes with I tried doing like FontFamily="../HUD/Fonts/fontname.ttf" I'm guessing this is incorrect way to do it since my xaml wont build with this. Any help is appreciated.
Effectively, .font files are no longer needed. But the way you use fonts is the same as in v1.1. You must set the property FontFamily to the desired family. For example:
FontFamily="Fonts/#Roboto"
This will use a .ttf file in the Font folder that includes the Roboto family.
Perfect I was tyring to use the .ttf name instead of the family name thanks.
 
wckdspn
Posts: 67
Joined: 18 Aug 2012, 23:14

Re: [Unity] v1.2 Preview

10 Oct 2014, 03:10

Some newly failing properties:
Ignoring unknown member Image.FlowDirection
Ignoring unknown member ContentPresenter.RecognizesAccessKey
Ignoring unsupported property 'IsGrouping' setting Trigger.Property
Also, the resolving of font paths seems to have changed, and it's now looks from the root of the Unity project. This is fine if it is intentional (much more consistent with Blend), just want to ensure it is so a fixup can be written. Image references still appear to be relative to the XAML though.
 
User avatar
sfernandez
Site Admin
Posts: 2983
Joined: 22 Dec 2011, 19:20

Re: [Unity] v1.2 Preview

14 Oct 2014, 12:51

Some newly failing properties:

Ignoring unknown member Image.FlowDirection
Ignoring unknown member ContentPresenter.RecognizesAccessKey
Ignoring unsupported property 'IsGrouping' setting Trigger.Property
Hi,

These properties were never really implemented, just defined (like many others) to make the xaml files build without errors. But sometimes people write about these properties not working (of course, there was no code using that properties), so we decided to remove the properties (and functions) from the API that are not doing anything, and just warn users that they are not supported (yet).
Also, the resolving of font paths seems to have changed, and it's now looks from the root of the Unity project. This is fine if it is intentional (much more consistent with Blend), just want to ensure it is so a fixup can be written. Image references still appear to be relative to the XAML though.
About the font/image paths we tried to solve the problems described in the issue 351 you posted in our bugtracker.

Now, when a URI is found in a xaml that uses the format "/ReferencedAssembly;component/Some/Path/Folder/image.png", we look up in the directory tree for the Blend project file. If the .csproj is found then we convert the resource path relative to the xaml path using the project file as the common path point to resolve it. If the .csproj is not found, then we treat resource path as a subdirectory of where xaml is located.

This is done for any resource reference: font, image, even merged dictionaries, so the behavior should be the same in all cases. If you are experiencing problems with this, please explain what is happening in the aforementioned issue in the bugtracker.

Thanks for your collaboration ;)
 
wckdspn
Posts: 67
Joined: 18 Aug 2012, 23:14

Re: [Unity] v1.2 Preview

15 Oct 2014, 01:35

These properties were never really implemented, just defined (like many others) to make the xaml files build without errors. But sometimes people write about these properties not working (of course, there was no code using that properties), so we decided to remove the properties (and functions) from the API that are not doing anything, and just warn users that they are not supported (yet).
Good to know! We'll just ignore it then.
About the font/image paths we tried to solve the problems described in the issue 351 you posted in our bugtracker.

Now, when a URI is found in a xaml that uses the format "/ReferencedAssembly;component/Some/Path/Folder/image.png", we look up in the directory tree for the Blend project file. If the .csproj is found then we convert the resource path relative to the xaml path using the project file as the common path point to resolve it. If the .csproj is not found, then we treat resource path as a subdirectory of where xaml is located.

This is done for any resource reference: font, image, even merged dictionaries, so the behavior should be the same in all cases. If you are experiencing problems with this, please explain what is happening in the aforementioned issue in the bugtracker.

Thanks for your collaboration ;)
For me, this works fine, though I'd be worried that it's possible it might trigger a csproj file that *isn't* the Blend project (for example, the proj files Unity makes for VS editing support... though those are at the same level). Would it not be possible to specify the path portion in the Noesis.ini? Or or you reading the proj file to verify the XAML files exist inside?
 
User avatar
Scherub
Posts: 141
Joined: 06 May 2014, 20:53
Contact:

Re: [Unity] v1.2 Preview

16 Oct 2014, 13:44

Hi,

can you tell me whether the latest changes of version 1.1.12 are already implemented in v1.2b?
 
User avatar
sfernandez
Site Admin
Posts: 2983
Joined: 22 Dec 2011, 19:20

Re: [Unity] v1.2 Preview

16 Oct 2014, 20:02

Hi,

can you tell me whether the latest changes of version 1.1.12 are already implemented in v1.2b?
Not everything, from the changelog these are the things incorporated to 1.2 version:
  • Fixed: Button not reacting to interaction when changing Visibility per frame.
  • Fixed: DefaultStyle padding bindings.
  • [Unity] Under certain conditions, Image Effects affects to NoesisGUI.
  • [Unity] Exposed UIElement.UpdateLayout() to C#.
  • [Unity] Support for passing string to HeaderedContentControl.SetHeader().
  • [Unity] Fixed: Noesis.UserControlSource not needed in not final classes.

Who is online

Users browsing this forum: No registered users and 30 guests