I have just noticed that when i call the following code from a console app
for (int i = 0; i < 10; i++)
{
Trace.WriteLine("Logging");
Debug.WriteLine("Logging Debug");
}
if I am targeting .net 4.0 no messages appear in the debugview app although I am capturing all outputs.
If I change to target 3.5 it appears fine.
What's changed and how can I fix it?
This is actually by design.
From Microsoft Connect :
The CLR has a new debugging
architecture where the CLR is native
debugging the application even when
managed only attached, and therefore
MS-SysInternals DebugView will not
work.
Are you doing this on the same machine?
It could be that the debug viewer (assumed DbgView from Sysinternals) is not connected. Check the title of the debug viewer for the name of the machine you're connected to.
This fixed the problem for me:
Trace.Autoflush = true;
Related
Windows 7 has an AWESOME new feature that applications can report the progress of the current activity through the status bar. For example, when copying file(s) using Windows Explorer, a progress bar is layered on top of the application icon in the task bar and the progress is shown as it updates.
What is the API for exposing the progress bar? Is there MSDN documentation on it?
For below .NET 4, or WinForms in any .NET version
Using the Windows API Code Pack from Microsoft (as Keeron mentioned), it's really simple. You just need to use the TaskbarManager. E.g.
To start the progress:
TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.Normal);
To update the progress:
TaskbarManager.Instance.SetProgressValue(currentValue, maxProgressValue);
And when when you're done, to end the progress:
TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.NoProgress);
There is more you can do, but that should get you started and might be all you need.
For .NET 4 and above with WPF
You can use System.Windows.Shell.TaskbarItemInfo. E.g. in the Xaml for your main window, you'll need to add:
<Window.TaskbarItemInfo>
<TaskbarItemInfo x:Name="taskBarItemInfo" />
</Window.TaskbarItemInfo>
Then to update the progress, you would do something like:
taskBarItemInfo.ProgressState = TaskbarItemProgressState.Normal;
for (int i = 0; i < 100; i++)
{
taskBarItemInfo.ProgressValue = i / 100.0;
Thread.Sleep(50); // whatever the 'work' really is
}
taskBarItemInfo.ProgressState = TaskbarItemProgressState.None;
Don't forget that if you're doing the 'work' on a background thread (which is probably a good idea for long running tasks), you will need to switch back to the UI thread to update the taskbar.
There's a good article in MSDN magazine about the new taskbar APIs. And yes, the feature is awesome :-)
Essentially, it's all about implementing IFileOperation. There's a good article about using it in managed code here.
If you plan to use other Windows 7 Taskbar features, another approach would be to use the library from Microsoft: Windows API Code Pack for .NET Framework which is no longer available at the old link, but can be found on nuget.
I've written an article about implementing the Windows 7 Taskbar progress API in C# (see: Windows 7 Taskbar Progress Bar with C# and .NET). The control is open source (BSD) and has example projects for C# and VB.NET.
This way you don't have to convert the C++ code from scratch.
Actually I use Telerik's RadWindow which you cannot just use <telerik:RadWindow.TaskbarItemInfo>. So I use this workaround for net6.0-windows WPF:
In code behind file I made a property:
public Lazy<TaskbarItemInfo> TaskbarItemInfo { get; set; } = new Lazy<TaskbarItemInfo>(() =>
{
return System.Windows.Application.Current.MainWindow.TaskbarItemInfo = new TaskbarItemInfo();
});
In method part of BackgroundWorker
private void WorkerProgressChanged(object sender, ProgressChangedEventArgs e)
I set the value of the progress:
TaskbarItemInfo.Value.ProgressState = TaskbarItemProgressState.Normal;
TaskbarItemInfo.Value.ProgressValue = (double)progressUserState.ProgressInPercent / 100;
In
private void WorkerRunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
I reset the state:
TaskbarItemInfo.Value.ProgressValue = 0;
TaskbarItemInfo.Value.ProgressState = TaskbarItemProgressState.None;
My question sounds simple: is it possible to remove the height limit of an app, if it is targeting Windows 8.1, but is also distributed to Windows 10 devices? Or is it my only choice just to upgrade project to target Windows 10, and distribute a separate package for it?
A related question:
How to specify initial window size for Windows 8.1 app running on Windows 10
..and an answer suggests "You could use reflection to call part of windows 10 sdk at runtime within your windows 8.1 app". Well, I have turned the whole Internet inside out, and I didn't find any normal explanation of this mystical method.
The method you've mentioned is use reflection to call ApplicationView.SetPreferredMinSize method at run time within Windows 8.1 app like following:
var appView = Windows.UI.ViewManagement.ApplicationView.GetForCurrentView();
var setPreferredMinSizeMethod = appView.GetType().GetRuntimeMethod("SetPreferredMinSize", new Type[] { typeof(Size) });
if (setPreferredMinSizeMethod != null)
{
setPreferredMinSizeMethod.Invoke(appView, new object[] { new Size(300, 300) });
}
Using this approach, you can reset the preferred min size and remove the default 768 height limit.
But please note that on Windows 10, Windows 8.1 app's ApplicaitonView is mainly controlled by system. If not necessary, please do not use reflection to do this.
The question is straightforward.
I am using VB.Net to develop Windows8.1(+10) application.
And, I want to detect if the OS version is 8.1 or 10. Not even want to know other versions like XP, 7 and 8.
BUT, Environment.OsVersion is deprecated,
cannot access into Registry in Windows8 APP(it's a policy even it's possible),
cannot generate custom manifest(blocked) file to retrieve version info,
cannot use 'Kernel32.dll'(policy problem) to extract.
How can I get the Windows version in Windows8.1 or Windows10 Store application?
Thanks.
Appended:
I want to retrieve Windows version (whether it is 8.1 or 10)
which is important for manipulating Live Tile.
not altering critical behavior or something mentioned in comment.
the Windows metro app provides slightly different method to pin tiles in Start Menu, which is very annoying to handle without knowing Windows version. Anyway, it is not the main topic.
VB.Net or C# code would be very appreciated.
It is not a 'give me the working code' thing.
This issue is not just on me,
it is also ongoing topic on other sites:
http://www.codeproject.com/Articles/678606/Part-Overcoming-Windows-s-deprecation-of-GetVe
http://www.vbforums.com/showthread.php?776481-Get-OS-version-Windows-8-1-does-not-detect
only thing is that either the solution is based on C++ or not applicable to Windows 8.1(metro app).
Thanks.
What you should be doing is checking whether the new methods are available. If they are available, use them, regardless of the operating system version. Example:
if (Windows.Foundation.Metadata.ApiInformation.IsMethodPresent("Windows.UI.ViewManagement.ApplicationView", "TryEnterFullScreenMode"))
{
Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().TryEnterFullScreenMode();
}
I didn't find any other way to do this, so here's my approach. (it's in C#, but you can easily translate it to Visual Basic)
The following property IsWindows10 detects if a Windows 8.1 or Windows Phone 8.1 app is running on a Windows 10 (including Windows 10 Mobile) device.
#region IsWindows10
static bool? _isWindows10;
public static bool IsWindows10 => (_isWindows10 ?? (_isWindows10 = getIsWindows10Sync())).Value;
static bool getIsWindows10Sync()
{
bool hasWindows81Property = Windows.ApplicationModel.Package.Current.GetType().GetRuntimeProperties().Any(r => r.Name == "DisplayName");
bool hasWindowsPhone81Property = Windows.Graphics.Display.DisplayInformation.GetForCurrentView().GetType().GetRuntimeProperties().Any(r => r.Name == "RawPixelsPerViewPixel");
bool isWindows10 = hasWindows81Property && hasWindowsPhone81Property;
return isWindows10;
}
#endregion
How does it work?
In Windows 8.1 the Package class has a DisplayName property, which Windows Phone 8.1 doesn't have.
In Windows Phone 8.1 the DisplayInformation class has a RawPixelsPerViewPixel property, which Windows 8.1 doesn't have.
Windows 10 (including Mobile) has both properties. That's how we can detect which OS the app is running on.
We are trying to debug through ninjectwebcommon.cs to find the binding for a respository.
In VS 2012, I am putting a Debugpoint on the kernel.bind but it doesnot hit anytime. Can someone sugggest me how to debug this?
I have NInject Version v4.0.30319
The not-so-simple and (obviously) temporary solution for me was to create a background thread in NinjectWebCommon.RegisterServices with the configuration I was debugging:
var thread = new System.Threading.Thread(() =>
{
while (!System.Diagnostics.Debugger.IsAttached)
{
System.Threading.Thread.Sleep(100);
}
// custom code, including kernel.Bind<>() calls here
});
thread.IsBackground = true;
thread.Start();
The idea here is to keep the thread you've created from executing the debuggable code until the debugger is actually attached. Setting the IsBackground property is important, because this allows the rest of the RegisterServices method to complete, which in turn allows the application to start and allows the debugger to attach.
Ninject is open source. You can download the entire project from their Github page at https://github.com/ninject. From there you can point Visual Studio to those projects instead of using the compiled assemblies.
Another option would be to use http://symbolsource.org as a Symbol Server. But it looks like they only have Ninject 3.
I'm getting an error trying to build a Silverlight application on a new machine. (Silverlight 4, Visual Studio 2010) This application compiles without error on four other machines.
The error is:
the tag 'MenuItem' does not exist in XML namespace 'clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Input.Toolkit'.
The references appear to be pointer to the correct assemblies. Has anyone else ever had this problem?
Another reason this issue may occur is due to missing a reference to all "three" assemblies required to use the portions of the the Toolkit controls.
Make sure you have reference to the following assemblies if attempting to use the Toolkit inputs (and assuming the themes also possibly).
System.Windows.Controls
System.Windows.Controls.Toolkit
System.Windows.Controls.Input.Toolkit
This solved the problem I was having in relation to the error.
http://marktinderholt.wordpress.com/2011/07/12/silverlight-toolkit-for-silverlight-5-beta
its the recompiled toolkit in SL5, just reference those and you're set
You can always fall back on creating the context menu in code.
public LedgerEntryControl()
{
InitializeComponent();
ContextMenu contextMenu = new ContextMenu();
MenuItem voidMenuItem = new MenuItem() { Header = "Void" };
voidMenuItem.SetBinding(MenuItem.CommandProperty, new Binding("Void"));
contextMenu.Items.Add(voidMenuItem);
ContextMenuService.SetContextMenu(this, contextMenu);
}
looks like you're missing the Silverlight Toolkit on that machine, but it's installed on the four other ones.
For some reason, the SilverLight Toolkit from NuGet Package Manager is for SL4, even when the project is set to SL5. You can download the SL5 version directly from CodePlex. Note that the date is December 2011, instead of February 2011 like the SL4 version.
If for some reason the MSI does not install (which happened to me), you can extract the files contained in the MSI using 7-zip. All I had to do was manually add a reference to System.Windows.Controls.Input.Toolkit.dll from the extracted files, and my SL5 project now compiles successfully with its NumericUpDown control. Happily, my program now compiles both in Release and Debug mode.
Also to add, for those who have not already done so, you may need to have a reference in the XAML to the correct toolkit. I used the following:
<sdk:Page xmlns:input="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Input.Toolkit" ... >
Note that the first part, where is says input, is what needs to be typed in the XAML to use the control:
<input:NumericUpDown x:Name="myControl" ... />