crashdome posted:

You could create a notification property like IsBusy and make the setter private. I do this because I usually want to disable more than one control/button.

Edit: Can't do code on my phone worth a drat. Basically make a property IsBusy and hook it up to OnNotifyPropChanged. Set it during any of your background tasks and change your RelayCommand enabled code to just check that property.

Manslaughter posted:

What would be the best way to have a .net 3.5 console app communicate with a .net 4.0 console app?

Drastic Actions posted:

I'm having an issue with a C++ library in a UWP. In VLC for Windows Store, we have a wrapper library in C++ that interacts with LibVLC (for handling video, audio, all that jazz). Right now there is a Windows 8 and a Windows Phone 8.1 version, with a shared base, each assigned to the correct universal project. In our UWP solution currently, the desktop X86 version points to the Windows 8.1 x86 version, the phone pointing to the Windows Phone 8.1 ARM version. Others on the team think that just recompiling these existing libraries should just work on UWP. However, if I try that, I get this:

System.BadImageFormatException (in VLC_WinRT.Services.RunTime.VLCService.Initialize

Now, those other wrapper use Windows 8.1 specific APIs that are not in UWP, so even if they did work, I think there would still be issues anyway. If I try and make a C++ UWP library with the same code, I still get the same error as above. I'm not sure what I'm doing wrong. Any ideas?

RICHUNCLEPENNYBAGS posted:

Do they run on the same machine? PowerShell may be an option.

ljw1004 posted:

EssOEss posted:

It rather depends on the overall devops workflow and how such policies apply. On my deployments, each product/service is completely independent and I would be aghast at hearing of some server-global configuration being applied to my service. The only configuration I want to see applied is that which my dev team and my operations team explicitly and intentionally configure, and such decisions are always done on a per-site basis, as each site is an independent product/service.

Overall, server-level configuration is something I have never seen, except on some forums and blogs where it has always smelled to me. But, to play the devil's advocate, I can imagine it making sense if you have e.g. 200 customer blog websites on one server that you manage and you want to enforce proper security practices on all of them.

What exactly is your scenario about? Why do you want to apply this header? To what sort of sites?

GrumpyDoctor posted:

What happens if you set the property via a style setter somewhere?

RICHUNCLEPENNYBAGS posted:

This is less a technical question, but now that Windows Runtime stuff can be windowed is that the way that desktop GUI stuff is going to go in the future? Are they going to invest in WPF and maybe make the XAML less unwieldy? It just feels to me like this is one area where C#/.NET/the MS universe has been weirdly stagnant.

Finster Dexter posted:

This header needs to be applied to address issues that come up in Acunetix PCI compliance scans. Some of these sites are basically marketing sites, but some are B2B management portals for the products/services we offer. There are also a small handful of consumer-facing sites for managing their end of things. Probably about 15-20 sites total that this needs to be done for across 5 or 6 server environements (some load-balanced, some not).

epalm posted:

Added this to my UserControl:

C# code:

public KeyboardNavigationMode TabNavigation
{
    set { KeyboardNavigation.SetTabNavigation(this, value); }
}

And this works like a charm:

XML code:

<wpfControl:ImageButton Text="Save Record" Image="/img/icons/silk/disk.png" TabNavigation="None" />

Thanks Doc!

EssOEss posted:

Perhaps it might be interesting to turn this question on its head: what needs do you have that are not being met by UWP? I wonder how big the needs for non-UWP apps will be in 5 years (in the context of something that actually has a GUI - obviously services and such are relevant).

GrumpyDoctor posted:

Oh, I was thinking of doing it entirely in the XAML but I'm glad you got it working

Mo_Steel posted:

I'm looking to move an application from a basic desktop executable to a Windows Universal App for Windows 10, and so far things have been going well; hamburger buttons and working in XAML is a change of pace from C# but not bad. I've run into a snag however:

The point of the application is to change the desktop background image, which I was previously doing using the registry. However, the Windows Universal App doesn't seem to allow that; if I add " using Microsoft.Win32; " I'm still unable to reference the RegistryKey class. I've read a few snippets about Universal Apps being self-contained in that regard, does that mean they can't access the registry period? If so, does anyone know off the top of their head if they exposed access to the desktop background image settings anywhere else, or could I round-about it calling something like a command prompt script or powershell script?

Drastic Actions posted:

You can't use Win32 in a UWP. You can't call the command line or powershell either.

You should be able to call "Windows.System.UserProfile.UserProfilePersonalizationSettings.Current.TrySetWallpaperImageAsync(StorageFile file)".

C# code:

            // This may not work if group policies are set on the machine to disable changing these settings.
            // Also not all devices support it either.
            // Make sure you check before you try it!
            if (UserProfilePersonalizationSettings.IsSupported())
            {
                UserProfilePersonalizationSettings profileSettings = UserProfilePersonalizationSettings.Current;
                if (useLocalFile)
                {
                    SelectedImage = await StorageFile.GetFileFromApplicationUriAsync(new Uri("ms-appx:///Assets/ejp.jpg"));
                }
                success = await profileSettings.TrySetWallpaperImageAsync(SelectedImage);
            }

I set up a Github Repo so you can check it out. There is one weird thing about it though: I can't get it to work with the file picker. If the StorageFile is from the file picker, TrySetWallpaperImageAsync will always return false, no matter what. If the file is stored in the apps storage, or bundled with it, then it's fine. So I think in your case if you download the image and store it in the app, or bundle it with it, you should be okay? I'm not sure if it's a bug in the API though

EssOEss posted:

There is apparently something called Project Centennial which enables oldschool non-UWP apps to be distributed via the Store, so you might not really need to make it an UWP app. It appears to still be unreleased even as a preview, though. Possibly even vaporware?

Mo_Steel posted:

Ahh, that makes sense.

For a little more clarity, I put together some code a while pack that goes and retrieves the Astronomy Picture of the Day and makes it the desktop each day when the user first signs in. I was hoping to move it up to a Universal App so people could get it off the app store and the like and as an excuse to toy around with UWP some, but it sounds like it'll be a total rework if it even functions. I've got the old, perfectly fine version out on a repo here and aside from when they post videos it works pretty great. I was thinking of moving to PowerShell to handle making scheduled tasks at "install" rather than the task scheduler c# wrapper I've been using.

EssOEss posted:

Perhaps it might be interesting to turn this question on its head: what needs do you have that are not being met by UWP? I wonder how big the needs for non-UWP apps will be in 5 years (in the context of something that actually has a GUI - obviously services and such are relevant).


I can't really give more input regarding your actual question but having gone through implementing PCI compliance in the recent past, I can share some advice on the actual PCI aspect. The main thing to understand here is that being PCI DSS compliant is about following a process, it is not about builing "secure" software, for whatever definition of secure.

This means that as long as warnings such as this one are properly understood, the impact documented and the risk taken into account, all is well. To reiterate, PCI compliance is about having a process that can detect and, if the stakeholders consider it relevant, help prevent vulnerabilities. However, there is no requirement to always follow every secure coding guideline in the world. If clickjacking is considered an acceptable risk by the product owner, having non-clickjacking-proof software is just fine as far as PCI goes.

I say this because it seems to be a common fallacy to believe that PCI means nailing down every leak and closing all vulnerabilities but this is just not the case. Obviously, many PCI consultants and auditors like to give that sort of impression since it gives opportunities for good upselling of various services that might otherwise not really be needed. Thankfully, our auditors were a reasonable bunch who helped us understand the real story and did not try to give us the runaround.

Drastic Actions posted:

"Windows.System.UserProfile.UserProfilePersonalizationSettings.Current.TrySetWallpaperImageAsync(StorageFile file)".

LeftistMuslimObama posted:

This is some simpleproxybeanfactoryfactor poo poo. That is one hell of a path.

Drastic Actions posted:

You don't have to use the whole thing, it was just to make it easer to explain where the namespace is.

EssOEss posted:

Perhaps it might be interesting to turn this question on its head: what needs do you have that are not being met by UWP?

Drastic Actions posted:

Updated my Github page. You can download images from there to apps local storage and it works just fine. You should be able to make a background task and schedule it every day to auto update too. Just as long as you're downloading the image to local storage, it should work.

fleshweasel posted:

I am really put off by the service locator/view model locator/big ball of singletons pattern. Am I crazy?