We Keep Coding

DirectX - Access denied when creating swap chain for CoreWindow

I'm currently trying to create a swapchain for a CoreWindow using the latest SharpDX as DirectX wrapper and UWP as project base framework.
The documentation on that is so sparse it's unbelievable. Nonetheless I could find a snippet which looked promising. Inititally I always got an E_INVALIDCALL error message. Now it's "only" E_ACCESSDENIED.
So far I've done this to set up the chain:
var description = new SwapChainDescription1
{
BufferCount = 2,
Flags = SwapChainFlags.None,
SampleDescription = new SampleDescription(1, 0),
SwapEffect = SwapEffect.FlipSequential,
Usage = Usage.RenderTargetOutput,
Width = 0,
Height = 0,
Scaling = Scaling.None,
Format = Format.B8G8R8A8_UNorm,
Stereo = false
};
CoreWindow window = CoreWindow.GetForCurrentThread();
if (window == null)
{
Logging.Error("Could not retrieve core window for swap chain.");
throw new Exception("Invalid core window.");
}
using (var device = _device.QueryInterface<SharpDX.DXGI.Device2>())
{
device.MaximumFrameLatency = 1;
using (Adapter adapter = device.Adapter)
{
using (ComObject coreWindow = new ComObject(window))
{
using (Factory2 factory = adapter.GetParent<Factory2>())
_swapChain = new SwapChain1(factory, _device, coreWindow, ref description);
}
}
}
The constructor of SwapChain1 throws the SharpDX exception:
SharpDX.Result.CheckError()
SharpDX.DXGI.Factory2.CreateSwapChainForCoreWindow(ComObject deviceRef, ComObject windowRef, SwapChainDescription1& descRef, Output restrictToOutputRef, SwapChain1 swapChainOut)
SharpDX.DXGI.SwapChain1..ctor(Factory2 factory, ComObject device, ComObject coreWindow, SwapChainDescription1& description, Output restrictToOutput)
RobInspect.Visualizer.Rendering.RenderingPanel.InitializeSizeDependentResources()
RobInspect.Visualizer.Rendering.RenderingPanel.InitializeDevice()
"HRESULT: [0x80070005], Module: [General], ApiCode: [E_ACCESSDENIED/General access denied error], Message: Access is denied.
"
Can anyone explain me why? "Access denied" is quite a broad statement and I'm not that experienced with DirectX's internals.
Further information: The code is executing on the main (UI) thread. So I guess I can exclude that the CoreWindow reference is inaccessible. Since this is first-time initialisation I also exclude the possibility of DirectX objects not being freed properly before creating the swap chain.
EDIT:
That's the code for creating the device. Whereas the flags are set to DeviceCreationFlags.BgraSuuport and DeviceCreationFlags.Debug. The levels are set to FeatureLevel.Level_11_1 down to FeatureLevel.Level_9_1.
using (var device = new Device(DriverType.Hardware, flags, levels))
{
_device = device.QueryInterface<Device1>();
_context = _device.ImmediateContext1;
}

The solution to this problem is that the terms WinRT Core and WinRT XAML are rather misleading. Since UWP is based on CoreWindow and both support and use them it's not clear where to use what.
DirectX exposes two methods for WinRT and one for Desktop. One being Factory2.CreateSwapChainForCoreWindow(...) and one Factory2.CreateSwapChainForComposition(...). The difference is that one takes the CoreWindow as parameter and one does not. And here's the trap I fell into.
Core stands for the design-scheme with which one only uses IFrameworkView and IFrameworkViewSource (see here for an example with SharpDX) whereas XAML stands for the traditional scheme where you have the Windows.UI.Xaml.Application class.
When using the Core-model you have to call the ...ForCoreWindow(...) method in order to create a swap chain. While using the XAML based approach you need a composition swap chain. I for myself already tried that, but failed because I forgot to enable (tip: do this if not already done) native debugging so the DirectX Debug Layer actually showed me essential information which could have saved me hours if not days of trial and error.
The issue here is that both composition and CoreWindow swap chains require special settings in the SwapChainDescription1. I'll leave you with the MSDN documentation. Moreover if native debugging and the debug layer is enabled, DirectX will tell you exactly what setting is invalid.

Fellow Oak DICOM - changing image window level

I am not an experienced programmer, just need to add a DICOM viewer to my VS2010 project. I can display the image in Windows Forms, however can't figure out how to change the window center and width. Here is my script:
DicomImage image = new DicomImage(_filename);
int maxV = image.NumberOfFrames;
sbSlice.Maximum = maxV - 1;
image.WindowCenter = 7.0;
double wc = image.WindowCenter;
double ww = image.WindowWidth;
Image result = image.RenderImage(0);
DisplayImage(result);
It did not work. I don't know if this is the right approach.

The DicomImage class was not created with the intention of it being used to implement an image viewer. It was created to render preview images in the DICOM Dump utility and to test the image compression/decompression codecs. Maybe it was a mistake to include it in the library at all?
It is difficult for me to find fault in the code as being buggy when it is being used for something far beyond its intended functionality.
That said, I have taken some time to modify the code so that the WindowCenter/WindowWidth properties apply to the rendered image. You can find these modifications in the Git repo.
var img = new DicomImage(fileName);
img.WindowCenter = 2048.0;
img.WindowWidth = 4096.0;
DisplayImage(img.RenderImage(0));

I looked at the code and it looked extremely buggy. https://github.com/rcd/fo-dicom/blob/master/DICOM/Imaging/DicomImage.cs
In the current buggy implementation setting the WindowCenter or WindowWidth properties has no effect unless Dataset.Get(DicomTag.PhotometricInterpretation) is either Monochrome1 or Monochrome2 during Load(). This is already ridiculous, but it still cannot be used because the _renderOptions variable is only set in a single place and is immediately used for the _pipeline creation (not giving you chance to change it using the WindowCenter property). Your only chance is the grayscale _renderOptions initialization: _renderOptions = GrayscaleRenderOptions.FromDataset(Dataset);.
The current solution: Your dataset should have
DicomTag.WindowCenter set appropriately
DicomTag.WindowWidth != 0.0
DicomTag.PhotometricInterpretation == Monochrome1 or Monochrome2
The following code accomplishes that:
DicomDataset dataset = DicomFile.Open(fileName).Dataset;
//dataset.Set(DicomTag.WindowWidth, 200.0); //the WindowWidth must be non-zero
dataset.Add(DicomTag.WindowCenter, "100.0");
//dataset.Add(DicomTag.PhotometricInterpretation, "MONOCHROME1"); //ValueRepresentations tag is broken
dataset.Add(new DicomCodeString(DicomTag.PhotometricInterpretation, "MONOCHROME1"));
DicomImage image = new DicomImage(dataset);
image.RenderImage();
The best solution: Wait while this buggy library is fixed.

Converting Standard C# to MonoTouch compliant code

I need to convert the following method from C# to MonoTouch compliant code:
private WritableBitMap CreateBitMapWPF(RGBPaletteRecord rgbPalette, double dpi)
{
WritableBitMap bitmapImage = null;
try
{
bitmapImage = new WritableBitMap(TileRecord.PixelWidth, TileRecord.PixelHight, dpi, dpi, PixelFormats.Rgb24, BitmapPalettes.Halftone256);
// int nStride = (bitmapImage.PixelWidth * bitmapImage.Format.BitsPerPixel + 7) / 8;
int nStride = (bitmapImage.PixelWidth * bitmapImage.Format.BitsPerPixel / 8);
System.Windows.Int32Rect rect = new System.Windows.Int32Rect(0, 0, TileRecord.PixelWidth, TileRecord.PixelHight);
byte[] data = GetBytes(rgbPalette);
bitmapImage.WritePixels(rect, data, nStride, 0);
}
catch (Exception ex)
{
}
//// temp write to file to test
//using (FileStream stream5 = new FileStream(#"C:\test.bmp", FileMode.Create))
//{
// BitmapEncoder encoder5 = new BmpBitmapEncoder();
// encoder5.Frames.Add(BitmapFrame.Create(bitmapImage));
// encoder5.Save(stream5);
// stream5.Close();
//}
//
return bitmapImage;
}
I'm not asking for someone to do the actual conversion, but I'm wondering what the best approach to take would be when converting this code? Should I focus on converting to use the MonoTouch libraries? Standard System libraries? Any advice would be much appreciated.
Thanks a lot,
Tysin
EDIT; Basically the purpose of this conversion is that I have these C# classes that perform a set of functions to do with bitmapped images, I'm using MonoTouch as I need to use these files in an iPhone application.

what the best approach to take would be when converting this code?
It depends on your goals and application(s). If you plan to share code across products / versions then you better have an API that abstract the platform details and separate code for each platform.
Should I focus on converting to use the MonoTouch libraries?
The WPF API is not supported on iOS (or MonoTouch). So you're closest bet is to look at the iOS API that MonoTouch provides (i.e. look at what's already available before looking at 3rd party libraries).
You'll find similar features by using iOS CoreGraphics (which in general is pretty similar to the older System.Drawing model). For bitmap image you should read the documentation of the CGImage type.
MonoTouch's CGImage documentation (C#)
Apple CGImage documentation

you should also look at this project :
https://github.com/praeclarum/CrossGraphics
made by Frank Krueger (gg!) it enable you to share the same basic graphics code between platform. It's an API that abstract the details implementation of each platform. For now it seems to be limited only to basic graphics (like fillrect and so forth....

QlikView's DynamicUpdateCommand() does nothing in C#

I'm playing with QlikView and was wondering if anyone has any experience with DynamicUpdateCommand()?
I can quite simpy get a .qvw file loaded and to display it on a form.
I can use doc.RemoveAllData(true) to, well, remove all the data.
I can't get DynamicUpdateCommand() to do anything at all...
Literally, RemoveAllData() changes what I see (everything vanishes), and DynamicUpdateCommand() changes absolutely nothing on the screen at all...
Does anyone know what I should be doing, or am doing wrong?
Sample code outside of my form...
QlikView = new Form2();
QlikView.LoadDocument(#"C:\myPath\myDashboard.qvw");
QlikView.Show(this);
QlikView.DoJiggeryPokery(#"INSERT INTO DataRuns (RunID, Value) VALUES (1, 1)");
Sample code for my form...
public partial class Form2 : Form
{
private QlikView.Doc document;
public Form2() {
InitializeComponent();
}
public void LoadDocument(string filename) {
document = axQlikOCX.OpenDocument(filename);
}
public void DoJiggeryPokery(string command) {
//document.RemoveAllData(true);
document.DynamicUpdateCommand(command);
//document.Reload(0);
}
}
I'm using the OCX for QlikView 9.0.0.

I don't use QlikView's C# OCX, but in QlikView's "Edit module" (VBScript or JScript) I activate dynamic update before performing it:
set curDoc = ActiveDocument.GetProperties
curDoc.EnableDynamicDataUpdate = true
ActiveDocument.SetProperties curDoc
set result = ActiveDocument.DynamicUpdateCommand("INSERT INTO DataRuns (RunID, Value) VALUES (1, 1)")
Hope you can adapt it for your environment.
Moreover it could be a problem of license. In Release notes for QlikView / QlikView Server 9.00 SR5 I read:
This functionality is freely available in stand-alone QlikView but requires an
additional license on QlikView Server.
Or additionally could be a bug like this: DynamicUpdateCommand stops working after QV restart.

I have been advised by QlikView support that this functionality exists but in unsupported. As such, we have abandoned this approach.

How can I send input to Visual Studio using Windows API

I am trying to develop a util (using system-hook) for that works like an expander (user selects some text and presses a hotkey and it is expands). It should work with Visual Studio.
I want to implement this using Windows API because I want to develop an app that works globally with any application (whether you're using VS, or wordpad, you should get the same functionality).
I've been able to do this successfully with notepad, wordpad, etc. using EM_ GETSEL and EM_REPLACESEL messages. But these APIs are not working with Visual Studio, or ms word.
What APIs should I use to be able to
1. Detect what text is selected.
2. Send input to the editor.
I am programming in C#. If you must know what I am trying to do... I am trying to make a universal port of ZenCoding that works on any editor. So all help will be appreciated.

For part 2 you could try using Windows Input Simulator which is an open source project I've just released to Codeplex to wrap the Win32 SendInput. Instead of SendKeys which just simulates text input, you can actually simulate real key strokes and complex chords to the active window.
In your case, if the user can perform the task with the Keyboard, this project will help you, otherwise you'd need to find another solution.
Hope this helps.

Why don't you use a System.Windows.Forms.SendKeys class for simulating keyboard input from user?
You can use:
SendKeys.SendWait("^C"); //CTRL+C
var selectedText = Clipboard.GetText();
var newText = Replace(selectedText);
SendKEys.SendWait("^V"); //CTRL+V

You can use WPF's Automation functionality, encapsulated in these two namespaces:
System.Windows.Automation
System.Windows.Automation.Provider
As an example, this is a method for finding an automation target element (e.g. a typical win control):
public static AutomationElement FindElement(AutomationElement context, PropertyCondition[] conditions)
{
// if no conditions, there's no search to do: just return the context, will be used as target
if (conditions == null)
{
return (context);
}
// create the condition to find
System.Windows.Automation.Condition condition = null;
if (conditions.Length <= 0)
{
throw (new ArgumentException("No conditions specified"));
}
else if (conditions.Length == 1)
{
condition = conditions[0];
}
else
{
AndCondition ac = new AndCondition(conditions);
condition = ac;
}
// find the element
CacheRequest creq = new CacheRequest();
creq.TreeFilter = Automation.ControlViewCondition;
using (creq.Activate())
{
AutomationElement e = AutomationContext(context);
AutomationElement target = e.FindFirst(TreeScope.Subtree, condition);
return (target);
}
}

Whatever you try, be absolutely sure to try it, ASAP, with Visual Studio 2010 beta 2. The editor has largely been rewritten, and hacks that work with an earlier version should be tested again.