Hi,
It appears that the majority, if not all uses of CreateExcelPackage, seems to work on a relatively flat object.
However we have a case where we have some sublists, eg:
Person: public long PersonId; public string PersonName; public List<Type> Types;
Type: public long TypeId; public string TypeName; public int TypeCount;
And we would want to present the data as follows:
PersonId, PersonName, TypeCountX....
The amount of types will be variable so we cannot statically set an object to a pre-determined number of types. However the CreateExcelPackage usages, seem only to be able to process the eg the longs and strings in this scenario, and not the sublists.
Im guessing therefore we will need to extend EpPlusExcelExporterBase and add our own function to handle the list?
Simon
Hi, we're updating our 5.6.2 project to 6.2.1
However one of the massive pains is the primengDataTableHelper.
We had to create all the right imports, and modify every tag that has p-dataTable to p-table, rename primengDatatableHelper to primengTableHelper, create a primeng-no-data div and now we realise we need to replace p-column.
Is there any kind of migration script available for this? Or do we literally have to search out every use of p-column and replace?
Regards, Simon Dean
Looks like you can create a "new" project with the same details as your existing one to get the new version. Looks like you can ignore the message about it downgrading your project limit.
In the ASP.NET Zero, there was a download button to download the latest version. Ours for some reason only goes up to 5.6.2. Where do we get version 6.2 from?
Regards, Simon
Hi,
The timezone is reported as Etc/UTC.
And bizarrely, I can now see a Timezone option under "My Settings" which wasn't there before.
What should we set for the United Kingdom - bearing in mind we alternate between GMT (Greenwich Mean Time) and BST (British Summer Time)?
Bearing in mind if we put a time in of say, 9pm British Summer Time, which gets converted to 8pm UTC in the backend, we still want to see 9pm during BST and also during GMT.
Regards, Simon Dean
Sorry for the delay in replying.
That article doesn't go too much into detail about where to set ClockProvider, but I have added this into the Startup.cs of the application, and this now seems to be passing back UTC Times correctly from ASP to Angular.
The Angular App (Service Proxies etc) is seeing the Z in the JSON showing that it is a UTC Time. So we're getting eg, 11pm UTC, but then just converting to a Moment of 11pm BST which is incorrect.
Regards, Simon Dean
Thanks for this. However as you can see, the service proxy does actually seem to convert to UTC time zone before submitting to the ASP.NET Zero server.
The problem appears to be in getting the time back from the ASP.NET Zero in that is it bringing in a time that is not denoted as being UTC and is therefore being treated as the local time zone.
So we submit eg 9pm BST, this gets sent and saved to ASP.NET Zero as 8pm UTC. When we get the time back, we get 8pm BST, and if we resubmit that time back to ASP.NET Zero, it gets saved as 7pm UTC. And the cycle continues. 7pm UTC > 7pm BST > 6pm UTC > 6pm BST etc etc
I'll have a look at those links to see if there's anything that might help with this.
Regards, Simon Dean
Hi,
We're using 5.6.0 of AspNetZero and we've noted a few issues with the way dates are handled.
When a Date comes in from the ASP.NET side of things, it comes in as a non UTC time, eg:
"startDate":"2018-10-02T00:00:00"
Within Angular, it refers to the moment being the local Time Zone of British Summer Time and displaying quite correctly. When we submit back to ASP, the service-proxy does a stringify and converts to a UTC time zone "startDate":"2018-10-01T23:00:00.000Z"
This then causes a problem because when we get the date back again into Angular, it is being treated as, eg in this instance, 1st October 2018 at 11pm British Summer Time.
So if we keep doing a submit and refresh, the time will just keep going back by an hour.
What can we do to resolve this?
Regards, Simon Dean
Can confirm this now works as expected in 5.6.2
Perfect. Thanks.
Simon