I have created a window application using Visual Studio 2017 template. CreateWindowEx expands to CreateWindowExW. I create an edit window this way:
LoadLibrary(TEXT("Msftedit.dll"));
hwndEdit = CreateWindowEx(
0,
MSFTEDIT_CLASS,
TEXT("Type here"),
WS_VISIBLE | WS_CHILD ,
100,
100,
100,
30,
gHwnd,
NULL,
hInst,
NULL);
MSFTEDIT_CLASS is defined as L"RICHEDIT50W" in Richedit.h This topic contains advice that I should use RICHEDIT_CLASSA (version 2.0). How to achieve it ?
Currently there are four versions for rich edit control:
Rich Edit Version 1.0
Rich Edit Version 2.0
Rich Edit Version 3.0
Rich Edit Version 4.1
The original specification for rich edit controls is Microsoft Rich Edit 1.0; the current specification is Microsoft Rich Edit 4.1.
It is suggested to use latest version for new application.
More detailed information about features supported on different versions you can refer to official document.
Related
My app is currently setting:
Xamarin.Forms.Forms.SetFlags(new string[] { "CarouselView_Experimental", "SwipeView_Experimental", "IndicatorView_Experimental" });
Can someone tell me if it's still needed to set these with Version 4.6?
As you can see in the official release notes for 4.6, the following are in preview and can only be accessed using feature flags :
Shell_UWP_Experimental
IndicatorView_Experimental
SwipeView_Experimental
AppTheme_Experimental
CarouselView_Experimental
MediaElement_Experimental
StateTriggers_Experimental
Markup_Experimental
Expander_Experimental
So, yes you need to still keep that code there if you are using those 3 features in Xamarin Forms.
Link for reference: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/release-notes/4.6/4.6.0-pre4
Is there a method to detecting the current programming language and disabling an extension based on that language?
I'm creating a VSIX package that is only compatible in a C++ build. I can programmatically detect the current programming language and respond to unsupported languages and not open my dialog box, but i feel like there should be a property or something that would enable/disable an extension in a certain language.
You can create a custom UI context rule for C++ and use it to load your package. It looks like this for C# and VB:
[ProvideAutoLoad(UIContexts.LoadContext)]
[ProvideUIContextRule(UIContexts.LoadContext,
"RightFileTypeOpen",
"(CSharpFileOpen | VBFileOpen)",
new[] { "CSharpFileOpen", "VBFileOpen" },
new[] { "ActiveEditorContentType:CSharp", "ActiveEditorContentType:Basic" })]
See How to: Use Rule-based UI Context for Visual Studio Extensions on MSDN and Mads Kristensen's sample for more details.
Can we get the fluid design in Windows 10 UWP app with Xamarin.Forms?
https://learn.microsoft.com/en-us/windows/uwp/style/acrylic
Jason is technically right since the feature isn't publically released yet. However, you should be able to try it already if you're in the Windows Insider Preview program. This is what you need:
Latest version of Visual Studio (2017, 15.3)
Latest Windows 10 Insider Preview SDK (probably 16267)
Latest version of the .NET UWP NuGet Package
You can check that you have the correct version if Windows.UI.Xaml.Media.AcrylicBrush is accessible.
Using with Xamarin.Forms: I haven't tried this myself but technically it should be possible. You'll need to roll out a custom renderer for the UWP platform where you define the Acrylic brush and add it to a control (Grid in this example). You also need to make sure to check that the XamlCompositionBrushBase is present and have a fallback for the case where it's not.
if(Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.UI.Xaml.Media.XamlCompositionBrushBase"))
{
Windows.UI.Xaml.Media.AcrylicBrush myBrush = new
Windows.UI.Xaml.Media.AcrylicBrush();
myBrush.BackgroundSource =
Windows.UI.Xaml.Media.AcrylicBackgroundSource.HostBackdrop;
myBrush.TintColor = Color.FromArgb(255, 202, 24, 37);
myBrush.FallbackColor = Color.FromArgb(255, 202, 24, 37);
myBrush.TintOpacity = 0.6;
grid.Fill = myBrush;
}
else
{
SolidColorBrush myBrush = new SolidColorBrush(Color.FromArgb(255, 202, 24, 37));
grid.Fill = myBrush;
}
This code is taken straight from the article you linked to but it should work as is in the custom renderer.
Please notice, that even if you get it to work, there might be major changes to the API and you'll have to rework your solution again and again.
How to create an EditBox using Win32 WinAPI so that it looks like the one you would get by placing an editBox in a VS designer in for example Visual C# or VB (with a nice top border etc.)? Here is an image of how it looks like and how it is when dropped in a designer:
I have tried this code:
hWndTextBox = CreateWindow(L"EDIT", L"My default text",
WS_CHILD | WS_VISIBLE | WS_BORDER | ES_AUTOHSCROLL ,
10,10,200,20,
hWnd,
(HMENU) ID_TEXTBOX,
hInst,
NULL);
But that one does not look like the box created in some .NET IDE designer. I have enabled visual styles in my Win32 application and I am using VS 2010 under Win7. I want it to look like the second one.
I must be missing some of the styles. I hope
Yup, you must use CreateWindowEx() so you can specify WS_EX_CLIENTEDGE instead of WS_BORDER. And use WM_SETFONT to set a decent TrueType font instead of the default Terminal.
To create such effect you need to subclass the Editbox control and override the WM_PAINT and WM_ERASEBKGND messages.
For info about subclassing see: http://msdn.microsoft.com/en-us/library/windows/desktop/ms633570(v=vs.85).aspx#subclassing_window
Is the documentation for Rich Edit Controls really as bad (wrong?) as it seems to be? Right now I'm manually calling LoadLibrary("riched20.dll") in order to get a Rich Edit Control to show up. The documentation for Rich Edit poorly demonstrates this in the first code sample for using Rich Edit controls.
It talks about calling InitCommonControlsEx() to add visual styles, but makes no mention of which flags to pass in.
Is there a better way to load a Rich Edit control?
http://msdn.microsoft.com/en-us/library/bb787877(VS.85).aspx
Here's the only code I could write to make it work:
#include "Richedit.h"
#include "commctrl.h"
INITCOMMONCONTROLSEX icex;
icex.dwSize = sizeof(INITCOMMONCONTROLSEX);
icex.dwICC = ICC_USEREX_CLASSES; //Could be 0xFFFFFFFF and it still wouldn't work
InitCommonControlsEx(&icex); //Does nothing for Rich Edit controls
LoadLibrary("riched20.dll"); //Manually? For real?
hWndRichEdit = CreateWindowEx(
ES_SUNKEN,
RICHEDIT_CLASS,
"",
WS_BORDER | WS_VISIBLE | WS_CHILD,
2, 2, 100, 24,
hWnd, (HMENU) ID_RICH_EDIT, hInst, NULL);
Using MFC, RichEdit controls just work.
Loading with InitCommonControlsEx() - ICC_USEREX_CLASSES doesn't load RichEdit AFAIK, you don't need it as it only does the 'standard' common controls, which don't include richedit. Apparently you only need to call this to enable 'visual styles' in Windows, not to get RichEdits working.
If you're using 2008, you want to include Msftedit.dll and use the MSFTEDIT_CLASS instead (MS are rubbish for backward compatibilty sometimes).
The docs do suggest you're doing it right for Win32 programming.
Many years ago, I ran into this same issue, and yes, the answer was to load the .dll manually. The reason, as far as I can remember, is that the RichEdit window class is registered in DllMain of riched20.dll.
Isn't there an import library (maybe riched20.lib) that you can link to. Then you won't have to load it "manually" at run time. That's how all the standard controls work. VS automatically adds a reference to user32.lib when you create a project.
I think you have to call CoInitializeEx before you create any of the common controls.
The LoadLibrary is not needed. If you link with the correct .lib file the exe-loader will take care of such details for you.