RichEdit Control EM_POSFROMCHAR Access Violation - winapi

I don't get it.
I sent:
SendMessage(hrichedit, EM_POSFROMCHAR, (WPARAM)pos, 0);
and pos=0x69
The documentation says:
wParam Rich Edit 1.0 and 3.0: A pointer to a POINTL
structure that receives the client area coordinates of the character.
The coordinates are in screen units and are relative to the upper-left
corner of the control's client area.
Edit controls and Rich Edit 2.0: The zero-based index of the
character.
lParam Rich Edit 1.0 and 3.0: The zero-based index of the character.
Edit controls and Rich Edit 2.0: This parameter is not used.
I'm pretty sure I'm using a Rich Edit 2.0 control and got the following:
Exception thrown at 0x00007FFE6A0121C6 (riched20.dll) in my.exe: 0xC0000005: Access violation writing location 0x0000000000000069.
I also confirmed looking at the CPU disassembly and it's trying to write to the address that is the value passed by pos.
What is going on?
I also thought maybe it wasn't 2.0 .. but GetClassName() returns RichEdit20W
The documentation also says:
Rich Edit 3.0 and later: For backward compatibility, Microsoft Rich
Edit 3.0 supports the syntax used by Microsoft Rich Edit 2.0. If
Microsoft Rich Edit 3.0 detects that wParam is not a valid POINTL
pointer, it assumes the message was sent using the Microsoft Rich Edit
2.0 syntax. In this case, it uses the return value to return the coordinates.
But clearly that's not the case.

The answer is that even though Visual Studio exception will occur, the exception is handled by the rich20.dll and returns the information correctly as if a RichEdit V2 control was used. It appears Win2K is when V3 started, so if you only have to deal with Win2K or later, you can use the V3 format, if needing NT4 support, you can use the V2 format and will work with V3 (also part of rich20.dll).

Related

What is msstdfmt.dll?

The file msstdfmt.dll is I believe supplied with Visual Basic 6 and is sometimes a dependency for deployment.
The copy on my PC includes the helpstring
Microsoft Data Formatting Object Library 6.0 (SP6)
which is not very informative.
What is this DLL for? What are the key functionalities that it provides?
According to Microsoft documentation:
The Microsoft Standard Data Formatting Object Library is required for
controls that implement a DataFormat property. An Application Error
occurs when a control makes an attempt to use the DataFormat property
and the Microsoft Standard Data Formatting Object Library is not
registered. Controls that implement a DataFormat property include, but
are not limited to, the following:
CheckBox, ComboBox, Image, Label, ListBox, PictureBox, TextBox,
ImageCombo, MonthView, DTPicker, Calendar, DataCombo, DataList,
DBCombo, DBList, MaskEdBox, RichTextBox.
It is used pretty extensively for data formatting.
It gets used implicitly with many databound controls and when you create databound UserControls or datasource UserControls and Classes. Instances of the StdDataFormat object it provides can also be used explicitly, either for direct use in code or even assigned to an ADO Field object's DataFormat property.
It is a pretty fundamental library for any VB6 program that is not written in "Let's pretend we are writing QBasic" i.e. Dark World scripting mode. Egad, you may as well be using stone knives and bearskins (a.k.a. Python).

Disabling visual styles in manifest while retaining Common Controls functionality

I'm using pure WINAPI, and need to send the TB_GETMETRICS message. However, that message only works if you add a manifest file to your application with a reference to Common Controls version 6.0. I added it, the message is working, but now my application is using Vista/Windows 7 visual styles, which I do not want.
Is there any way to keep the Common Controls 6.0 reference while using Classic theme, either by modifying the manifest file or by calling some API function?
Note: I tried SetWindowTheme but the result was a mix of Classic and Aero.
EDIT: I hadn't read the SetWindowTheme function correctly, so I was thinking calling it for the parent hWnd would automatically call it for all its child. It turns out I need to call it for each control I want to use Windows Classic. It's working as it should now.
To disable visual styles for all controls, call SetThemeAppProperties(STAP_ALLOW_NONCLIENT) or SetThemeAppProperties(0) before you create your main window.
To disable visual styles per HWND you can call SetWindowTheme(hwndControl,L"",L"")
If you need to support systems without v6 common controls you can probably figure out which system metrics (or hardcoded values) are used in the toolbar control by playing with the system metric values and system DPI.
Solved by using SetWindowTheme (with L"" as parameters) properly: all I had to do was call it for each and every control my application creates. It feels hackish but gets the job done.

Custom property pages not titled in Outlook 2003

I am implementing a custom Outlook Property page in C++ as an ActiveX control as per this article.
Basically, I have noticed that when passing an initialized object (my ActiveX object) to the 'raw_add' method on the property pages obtained within the namespace event 'OpetionsPagesAdd', the second parameter (the property page tab title) is ignored in Outlook 2003. In 2007 and 2010 my code works absolutely fine, only in 2003 does that second parameter seem to be ignored.
I'm sure I have come across articles in the past describing this as a known bug in Outlook 2003, but I was wandering if anyone had found a way around the issue? I found this article describing the same issue, and the resolution, but that is for C#, and I can't for the life of me see how to port his 'fix' to C++.
I ended up raising a support case with Microsoft for this issue, and it is a bug in Outlook 2003. The way around it is to derive from public IDispatchImpl and define the caption property in the prop map:
( PROP_ENTRY_TYPE("Caption", DISPID_CAPTION, CLSID_PropPage, VT_BSTR)
Then implement the put_caption and get_caption methods and it should work.

Using Message Boxes in Windows 7 style

After reading the MSDN article about proper user interface here:
http://msdn.microsoft.com/en-us/library/aa974176.aspx
I want to modify the message boxes I use in my applications to reflect those guidelines (for example, have the Main Instructions in a larger font, better named Buttons, etc...).
My question is, is there an API that allows you to easily build those kind of message boxes (a la user32\MessageBox()), or do you actually have to build your own message boxes which follow the guidelines?
Mostly you just get that (try it and see!) when you use MessageBox or whatever wrapper applies in the language you're using (you didn't say.) There is also Task Based Dialog which goes well beyond the yes/no/cancel world of message box. There is a Win32 API for that if you're in C++, and the Windows API Code Pack has a wrapper if you're in C# or VB.NET.

Which VB6 controls are supported by Microsoft?

I'm looking for a replacement for the Sheridan 3D Panel (ssPanel) and I'm trying to figure out which of the Controls in the Projects>Components I can add to my project which will be supported by Microsoft. (I.e., I don't want to add a control that MS doesn't officially "support", like the MS Forms 2.0 Object Library).
Update
Microsoft does still support VB6 (or at least the files that it uses)
There is no list of supported controls: you have to look at the list of supported OCX files in the Microsoft Support Statement for VB6. You need to figure out which controls are in those OCXs. You could start a new VB6 project, tick the OCXs in Project-Components, and see which controls become available in the toolbar.
Confession I have made this answer Community Wiki, because this information was originally in a comment to another answer, but that answer is now deleted. Feel slightly guilty as I downvoted the answer (it said VB6 is unsupported which is misleading).
What part of the SSPanel behaviour do you need?
If it's the custom appearances (raised 3D edge etc.) it's not too hard to write a user control based on the intrinsic VB6 Label and Line controls. Have a look at the edge of the SSPanel in the magnified screenshot below. It's just a one pixel border. The colours are system colours: left and top are "button highlight" &H80000014& and the right and bottom are "button shadow" &H80000010&. Put four line controls in a user control and write code in the resize event to move them to the edge of the control.
alt text http://img194.imageshack.us/img194/5376/sspanelzoomin.png
If you need a label that can act as a container, you could make your user control capable of being a container (set ControlContainer True).
Vertically centred text. Offhand I don't know a good way to do that. Google is suggesting creating a user control with a PictureBox and using the TextHeight method.
EDIT There's another approach, which I'm using in some of my projects. Just continue to use the SSPanel despite it's being unsupported and with awareness of its various problems. It does seem to work fine on Vista and XP - haven't tested yet on Windows 7.
Just as a side note to expand on MarkJ's thought (I realize this question is a little old, but I recently had to deal with porting some old VB apps): There are some cases where SSPanel is used as a container with background colors, and without text. Although it may seem like stating the obvious, the Forms.Panel does work fairly well class to avoid the "Sheridan 3D Controls" dependency and make distribution easier in these simple cases.
The VB.net converter tool may generate something like:
Public WithEvents ssPanel As AxThreed.AxSSPanel
Me.ssPanel = New AxThreed.AxSSPanel
ssPanel.OcxState = CType(resources.GetObject("ssPanel.OcxState"),
System.Windows.Forms.AxHost.State)
CType(Me.ssPanel, System.ComponentModel.ISupportInitialize).EndInit()
Which is easily changed to:
Friend WithEvents ssPanel As System.Windows.Forms.Panel
me.ssPanel = New System.Windows.Forms.Panel
' No longer necessary:
' ssPanel.OcxState
' CType(Me.ssPanel, System.ComponentModel.ISupportInitialize).EndInit()
A comment from MarkJ made me re-read the Q, and from "replacement" I now understand this is likely a re-code/new version project, not a start from scratch... the original answer below is not accouting for that.
Meanwhile, MS says it's suportting a core runtime file of a language that has no roadmap or committed resources (?), so bottom-line of my answer still stands: vb6 stopped, new projects can go Python, vb.app, java, c++, C#, whatever.
Original:
None. VB6.0 reached its End-Of-Life. Go Python! or Java, or C#... never vb .net, because it's tons harder/dense than Java, not VB6.0 syntax in the slightest, and the learning curve is just a notch under C#.
P.S. It's so interesting to have negative votes because I trashed vb .net when compared to java or c#.
I wonder what these guys would think of me, being a former vb6 programmer, and not moving to any of the .net flavors.

Resources