Alright so just to confirm if i understood. If i search globally for a reference of the key / value pair and do not find anything refering to it i can ignore it, which means i can safely delete it without destroying my UI right?
Familiarize yourself with the "patterns" used to access resources; to satisfy yourself that your searches are hiiting the "right things" ... e.g. "$this.Icon" is the "key" of the "resource" is this case:
Well, i use this "pattern" for my global resources and there i have no problems. What i am specifically pointing to is the resource files generated for each usercontrol as soon as you set the control to localizable true. And after doing that there was a lot of useless (as mentioned before like docking position) stuff autogenerated into the resource file instead of still being in the designer class.
But since i was not sure how to handle this, because the designer sets the resources according to the culture of the system or the one in which i start up the app during initialization of the usercontrol, i asked wether it is possible to remove those lines from the res files back to the designer without destroying the layout of the usercontrol.
So i would actually never find a "hit" since all the initialization in the designer.cs does this ->
I define a HtppWebRequest ending with the following lines : ...
req.Credentials = new NetworkCredential(...);
Stream theStream = req.GetRequestStream();
theStream.Write(bytes, 0, bytes.Length);
Then, the request is sent twice. A first time with the theStream.Write line, and a second one with the req.GetResponse() line. I have a 401 (unauthorized) response with the first request and a 403 (forbidden) with the second one.
I Wonder if the 403 error is due to the previous 401.
In any case, I would not to send the first request.
we are using this code to read xml file, we want to optimize the code .
Issue is that in our xml file around 50 attributes are there , but from that we want hardly 2 to 3 attributes value.
but here while loop is executing 50 times , that we don't want.
Please give suggestion .
using (XmlReader reader = XmlReader.Create(@"C:\abc.xml"))
while (reader.Read() )
this might not be a real question, more like an interest about, how bad my current workaround is. I hope it's OK to post here .
I have an application which I have started developing for WPF and now I also want to port it to UWP. I have created some custom visual controls for the app in a Controls library, which is a Class Library in C# and references .Net WPF libraries.
Some custom panels would look very similar with code working in both frameworks, so I thought it would be nice to reuse my old code.
This is the solution I came up and currently porting the library to:
- left the original Controls class library project untouched
- created a Controls.UWP class library for UWP platform
- added source files from Controls to Controls.UWP as linked files
- finally - and currently working on - resolving the namespace changes by adding stuff like this at the beginning of source files:
However, in some cases I must completely rewrite the class eg. because I used OnRender function to draw it, so now I have to rewrite it to use Win2D. For this reason I don't know if it's worth bother with #if statements.
Thank you for the reply! Then I guess, I wanted to create a monster with platform specific code (the UI controls) for two frameworks in common source files.
I have already used PCL, that's why I thought it would be nice to have something similar for UI, too.
Also, since my post I found other issues, like the missing FrameworkPropertyMetadata from UWP and more restricted attached property accessors. So, it seems, that I couldn't save anyway as much code-rewriting as I wanted .
The biggest problem you will face is that, despite appearances, WPF and UWA are two vastly different beasts. Universal Windows programs are a lot closer to Silverlight, so there are things that you can do in WPF that just aren't available in WPF (and vice versa). This would have a fundamental impact on things such as what your XAML does, which would be a major pain to work around.