We are upgrading from v2 of tilelayer to v3. In v2 we had access to 30 default schemes/styles from Here.
normal.day
hybrid.day
normal.traffic.day
etc.
It looks like in v3 we only have access to 4.
explore.day
explore.night
explore.satellite.day
satellite.day
Is it possible to get or create the other styles, particularly the traffic styles?
This is entirely related to the version you are using:
If you have upgraded to version 3.0, you can use this tool:
https://demo.support.here.com/examples/v3/mrs_options
Where you will be able to change to the exact schema you are looking for and play with the parameters such as "Tile Type".
But, if you are using version 3.1, you must check the following tool:
https://demo.support.here.com/examples/v3.1/simple_raster_map
Where you can see the implementation of these "schemes" and "styles" is a bit different, this is by selecting the view you are looking for.
We hope this is helpful for you.
Just a quick note:
This is only available for users who have a developer here account.
Related
I can't find the reports plus in my Rhapsody v8.1.2 x64
anybody knows the reason.
I also need to make custom profile to generate documents out of the design. I am thinking of using the ModelBasedDocumentGeneration profile but I can't find any help how to use it.
I'd appropriate if any one can recommend something (materials or another way to make the reports)
P.S. I don't have Rational Publishing Engine
This is one of the missing features in the 64 version according to this link:
http://www-01.ibm.com/support/docview.wss?uid=swg27038779
It seems that Xunit no longer supports extending TraitAttributes. They have sealed the class.
There are also some other issues with Autofixture's plugin for AutoData() where we can inject random created data through an attribute. There are a few work around's for this, however I am attempting to evaluate this for a larger product overall. I liked the demo's since they could do small things like SQL, Excel, custom Attributes for category.
It seems there was more functionality before the changes. I have looked at the site and still see some of the features are returning and there isn't much information.
Is there a new set of functionality coming out? Or possibly a change that will allow us to recreate the older functionality in a new way? It seems the SQL and Excel have a work around, however I can't find any information about when the latest version will be compatible with "Autofixture with xUnit.net data theories" Nuget package. I really like what I have seen, though I can say I don't like breaking changes when I look at enterprise solutions. I cringe a little when I think about if I had this in place in an enterprise and I had made a lot of custom attributes, or used Moq and Autofixture to populate and now all my tests were broken. So I guess the other question is, does Xunit seem to change a lot with breaking changes? There is the other option of moving Xunit back a version. Though at some point I would need to know if these things would be fixed or if they were permanently removed, since I wouldn't want to spend time using functionality that is being removed.
Another is AutoFixtureMoqAutoDataAttribute that doesn't load without that side Nuget package. With the side nuget packages not being updated.
I guess the end question may be.. Does anyone know of any plans to get these features to work with the current version of xunit so that I can start implementing and then expect to do mass replaces later? Or are these permanently breaking changes where we shouldn't implement anything that is currently missing.
Thank you in advance.
Short answer
If you want to use xUnit.net 1.x with AutoFixture, use AutoFixture.Xunit.
If you want to use xUnit.net 2.x with AutoFixture, use AutoFixture.Xunit2.
Explanation
xUnit.net 2.0 introduced breaking changes, compared to xUnit.net 1.x (e.g. 1.9.2). For AutoFixture, we wanted to make sure that AutoFixture supports both. There are people who want to upgrade to xUnit.net 2.x as soon as possible, but there are also people who, for various reasons, will need to stay with xUnit.net 1.x for a while longer.
For the people who wanted or needed to stay with xUnit.net 1.x for the time being, we wanted to make sure that they'd still get all the benefits of various bug fixes and new features for the AutoFixture core, so we're maintaining two parallel (but feature complete) Glue Libraries for AutoFixture and xUnit.net.
As an example, we've just released AutoFixture 3.30.3, which addresses a defect in AutoFixture itself. This bug fix thus becomes available for both xUnit.net 1.x and 2.x users.
Thus, when you need to migrate from xUnit.net 1.x to xUnit.net 2.x, you should uninstall AutoFixture.Xunit and instead install AutoFixture.Xunit2. As far as I know, there should be feature parity between the two.
Traits
AutoFixture.Xunit and AutoFixture.Xunit2 don't use the [Trait] attribute, so I don't know exactly what you have in mind regarding this.
AutoMoq
Again, when it comes to AutoFixture.AutoMoq, it doesn't depend on xUnit.net, so I don't understand the question here as well. It sounds like a separate concern, so you may want to consider asking a separate question.
When you create a new .pubxml in Visual Studio, it has a set of basic properties defined under the top-level PropertyGroup element (e.g. properties WebPublishMethod, DeployIisAppPath, etc.). But I've found it hard to find any documentation for exactly what those properties mean, let alone a reference for the full set of optional tags/properties that one might be able to use in a profile. Does such documentation exist? So far the only method available for learning about a lot of the tags/properties is to see at other people's example .pubxml files.
Hopefully someone can prove me wrong, but it seems hard to surface such docs by, say, googling.
Probably the best source of information is the Microsoft.Web.Publishing.targets file (found in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\ - adjust the v14 to v10 or v12 for your version of Visual Studio)
There are some comments in this file, as well as the fact that this is the MSBuild file that uses those property values - so even if a particular property isn't commented, you might be able to figure out their purpose.
I have few questions about the google map v3 which I am planning to use it my intranet website. Before that
1)
I tried sample application by using the below URLs.Both working fine.
Which one is best ? seems both belongs to V3 ? Can i use it for free ?
http://maps.googleapis.com/maps/api/js?sensor=false
http://maps.google.com/maps/api/js?sensor=false
2)
Am planning to use this v3 URL to locate my stationary stores in my state?
Do I need to buy license for that ? If yes, Do i need to change the URL ?
Go into your api console and grab an API key, then go from there:
https://developers.google.com/maps/documentation/javascript/tutorial#api_key
I tried sample application by using the below URLs.Both working fine.
Which one is best ? seems both belongs to V3 ? Can i use it for free ?
http://maps.googleapis.com/maps/api/js?key={API_KEY}&sensor=false
Go for the first one according to official documentation. But the thing is, what happened to your API key anyway!?
As for whether you can use it for free, read here. (Please show your effort before asking things like these)
I'm storing information in a custom property sheet for one of my custom products (I'm then using that information in a javascript file). I want this product to uninstall cleanly, but I can't seem to figure out how to remove a custom property sheet on uninstall using genericsetup. I know that remove="True" doesn't work, but I'm not having much luck figuring out the correct way (or any way for that matter) for removing this. Any suggestions would be greatly appreciated.
This is confusing for at least two reasons:
We have both "old style" and "new style" technologies actively in use. Old style refers to Extensions/Install.py (Python code) and new style refers to profiles/default (GS XML + setuphandlers.py Python code).
Successfully installing and uninstalling add-ons in all possible cases still requires the use of both old and new style technologies.
If you don't care about uninstall, you never need to use Extensions/Install.py. If you do care about uninstall, create an Extensions/Install.py with install and uninstall methods.
Also create an "uninstall" profile (in addition to the "default" profile) e.g. profiles/uninstall. Configure the Extensions/Install.py:install() method to execute your "normal" profiles/default steps on installation. Now comes the "fun" part.
Because some technologies can be uninstalled "properly" via GS i.e. they respect the remove=True parameter, your Extensions/Install.py:uninstall() method should execute the "proper" GS profiles to do the uninstall. But if your add-on uses technologies that cannot be uninstalled "properly" via GS i.e. those that do not respect the remove=True parameter, then you will need to write Python code to perform the uninstall.
See:
http://plone.org/documentation/kb/genericsetup/creating-an-uninstall-profile
for more information.