I will be posting some sneak peak screen shots of the upcoming version 17.0 beta that we will be releasing soon.

The first screen shot is shows off some of Calendar enhancements that have been made. We have completely rewrote the Calendar theme engine to make it easier to introduce new themes. We have also added "from" and "to" arrows for multiday events, and improved the overall appearance for Calendar and Date Picker Office 2013 themes including event selection which now shows bolder border and sizing grippers.

Also, with the Visual Studio 2015 themes we introduced state colors similar to how Visual Studio will change the frame and status bar colors when you open a new solution or run the debugger. This can be set to any color of your choosing.

Yes, this is one of the areas that will be addressed with the next release. We also recommend that you use pre-defined icons for various resolution rather than letting the framework scale them as some icons do not scale very well. This is how other applications such as Word handle it.

Calendar looks nice. But since I don't use it, I'm looking forward to the other promised changes in the next release.

I'm really waiting for the numerous High-DPI fixes you have promised. Many of my users work on screens with 150% to 250% (144 - over 200 DPI, compared to the 96 DPI you hardcoded in several places). Having 3200 pixels on a 13" screen (Dell) is no fun if the application you work with messes up the font sizes.

Just had the case today that a CXTPControlComboBox on a 200% screen produces unreadable text because each line folds half-way into the previous line. As far as I could tell, this control uses a font derived from the system icon font (???) and so should work. But does not. Maybe using the default Windows control font size or the menu font size would be better.

Panel icons use a hard-coded size of 16 pixels. No way to change them, even if my application is configured to use 32 or even 64 pixel icons.

My code automatically adapted to all high-DPI screens, but I had to spend far too much time making XTP work - and in some places could not make it work at all. This is annoying for me and the customers, and expensive as well. I really hope that your new update gets all this fixed without breaking existing code.

I'm also looking forward to proper DPI-aware XAML code. So far I need to manually parse all XAML produced by my users and manually correct the font sizes etc. to match the DPI of the output device context. You have hard-coded 96 DPI in your XAML source code.

I would also very much like to have the ability in markup to use point sizes (or maybe something like 'em)' for Margins, Padding etc. Using pixel values for these measurements makes it impossible to write XAML markup that adapts to different DPI settings in the output device context. This should not be hard to do I hope.

I consider the (albeit limited) XAML support in XTP indeed as a great feature, because it makes a lot of things easier or more flexible. So far unfortunately only if you work on monitors with 96 DPI - which seem to die out quickly.

This is just to confirm that the upcoming version introduces full DPI support for the following components: CommandBars, Ribbon, all controls, Shortcut Bar, Docking Pane, Task Panel, Tab Manager and Markup. Note, for backward compatibility reasons CommandBars and Markup will have DPI support disabled by default. In order to enable DPI support for command bars use this code after a theme is applied:

pCommandBars->GetPaintManager()->m_bAutoResizeIcons = TRUE;

pCommandBars->GetCommandBarsOptions()->SetDPIScallingOptions(TRUE);

In order to enable DPI support for markup set a new bDpiAware argument of XTPCreateMarkupContext to TRUE, or call CXTPMarkupContext::SetDpiAware method.

We appreciate a thorough testing and reporting any issues found in the upcoming beta version.

When I feed in 16 or 32 pixel icons and enable this option, the command war will do what with these icons? I want to avoid blurry icons... Currently my app uses 16,24,32,48 pixel icon sets and uses them with control bars depending on options set by the user and the system DPI setting. How does "auto icon scale" fit into such a scenario?

You mention TabManager. I assume I can use icons > 16 pixels now? If so, how?

When I enable this new XAML option with CXTPMarkupContext::SetDpiAware this affects which operations? Only font size calculations? Or are other measures in the markup also scaled to meet the DPI settings of the device content? If so, which?

Is there a way to specify margins, padding or distances with a non-pixel unit that is automatically scaled (pt or em)? Just scaling font sizes given in pt unints is unfortunately not enough. We need a non-pixel unit for other distances/sizes too. Did you consider that in your new code?

I apologize for asking these questions here, but your documentation is usually not very helpful. A flag like "m_bAutoResizeIcons" is usually documented as "Enable or disable auto resize icons" - which does not tell us much. When to use it? How to use it? How are the icons resized? To which size? How to feed in different base icon sizes to avoid scaling and blurry results?...

Does the calendar on x64 platform will work with MAPI and Outlook 2013 x64. Currently, it doesn't. Have you added some improvments to the calendar like being able to add contacts to a meeting for example.

>>> When I feed in 16 or 32 pixel icons and enable this option, the command war will do what with these icons? I want to avoid blurry icons... Currently my app uses 16,24,32,48 pixel icon sets and uses them with control bars depending on options set by the user and the system DPI setting. How does "auto icon scale" fit into such a scenario?

This option enables icons scaling, if your icon images have ICO format, not bitmaps, the most suitable size will be choosen during scaling. But if you want your icons to looks as sharp as possible you can disable this option. You can play with it in different DPI using the RibbonSample (Options -> Font) and see how it fits your needs and expectations. There is no really good trade-off in this case as only vector images would produce seamless scaling, which is definitely not a case here.

>>> You mention TabManager. I assume I can use icons > 16 pixels now? If so, how?

Same is true for tab manager.

>>> When I enable this new XAML option with CXTPMarkupContext::SetDpiAware this affects which operations?

It affects everything rendered by markup, including font sizes. And we preserved standard WPF behavior when it comes to DPI scaling (https://msdn.microsoft.com/en-us/library/ms748373.aspx - 'About Resolution and Device-Independent Graphics'), meaning it will scale Xpt font size.

>>> Is there a way to specify margins, padding or distances with a non-pixel unit that is automatically scaled (pt or em)?

Please clarify what exactly you are asking about, some sample would be useful.

>>> .. but your documentation is usually not very helpful.

Unfortunately it is not detailed enough and we are aware of it and gradually provide more detailed descriptions to portions of code that we work with, so as before the best source of information is the code of the sample applications and the toolkit source code itself for more rigorous learning.

Please clarify what exactly you are asking about, some sample would be useful.

I'm sorry if my comment was confusing. Your markup documentation is rather limited. Using it means looking up the sparse comments in your help file, then looking up the documentation of the parameters mentioned there in MSDN, then looking in your code which part of the official XAML feature you have actually implemented.

I understand that your next release will scale the FontSize of 12pt according to the DPI settings of the output device context. Good.

But what about the Margin of the <Border> element. According to the XAML spec:

The default unit for a Thickness measure is device-independent unit (1/96th inch). You can also specify other units by appending the unit type strings cm, in, or pt to any measure.

It seems that the default unit for Margins or Padding in your XAML implementation is pixel, and that I can use pt in addition?

<Border Margin='10pt,10pt,10pt,10pt'>

If you scale the FontSize, do you also scale other measures given in pt, cm or mm? Do you support pt, cm or mm for Margins, Padding, Rectangles, Width, Height etc. in the next release and do you scale these measures as well? Scaling only the FontSize will break existing XAML layouts otherwise. If the font's are suddenly twice as big on a 200% screen, Margins, Widths and Heights also need to grow accordingly, or existing markup will break.

I would welcome an answer to my XAML-related questions, if you find the time. I'm not interested in the calendar or gauge controls or Windows 10 / Office 16 themes at all. I prefer the basics to work correct first.

Please focus all your energy an 17.0 first. Unfortunately there is still no beta.

I agree and that is exactly we are currently doing. We have been working hard and so far I am pretty optimistic for being on track with Beta 1, it should be ready sometime next week. I am not sure it will be Monday as originally planned, but defiantly by the end of the week, this is our goal.

As an update we are preparing the build for Beta 1 but ran into a small snag, our Code Signing certificate has expired and we cannot sign any of our binaries (.exe, .dll, .ocx) until we get the new cert. We renewed this back in November of 2014, but did not realize our Duns and Bradstreet information was out dated because we moved our offices to a new location, so we could not get validated.

So now we are waiting for DnB to update their information so we can complete the validation process and get a new certificate issued. We are working on providing them alternative means of verification but they are pretty strict on this. DnB informed us that it may take as long as 14 days for a the information to be updated, but we are hopeful that we will not have to wait that long and they will accept our alternative documents.

So this is what is holding up our Beta release at the moment, I apologize for the delay, and I will let you all know as soon as we hear something.

This probably wouldn't of been a big concern for our MFC clients, however I was a bitconcerned about shipping the unsigned OCX files for our ActiveX clients. The good news is we were able to get this whole mess resolved today and our new code signing cert has been issued. We are doing a final build now for Beta 1 and should have the downloads ready by this weekend.

Toolkit Pro, Suite Pro 17.0.0 Beta 1 ReleasedCustomers who have an active maintenance subscription for any Toolkit Pro or Suite Pro product will find the beta download under My Account > Product Download. Select your product to see the download link for the current beta. We will announce additional beta releases using the RSS feed on our website and the Codejock Messenger alert that is installed with each product.

I would welcome an answer to my XAML-related questions, if you find the time. I'm not interested in the calendar or gauge controls or Windows 10 / Office 16 themes at all. I prefer the basics to work correct first.

What have you found out now that the v17 beta is available? Does it answer your questions? I ask because I have the same ones, but haven't had time to dig yet.

We had some good feedback on Beta 1 so we are working hard on addressing those issues. Realistically we are probably another 2 - 3 weeks out before we are ready for Beta 2. This should address the majority of outstanding issues that have been brought to our attention.

Realistically we are probably another 2 - 3 weeks out before we are ready for Beta 2.

Really? Are there sooo many bugs or are they sooo hard to fix? Three weeks between the betas should just be fine, IMHO as professional programmer.Please release something soon, and release a further RC1 and RC2 perhaps...

Speaking about bug fixes in beta versions: It would be really helpful to have a powerful customer bug/issue tracking system, like e.g. Asterisk has (jira, mantisbt etc.).As customer I can see and track if an issue is fixed in a certain (beta) release and additional infos can be exchanged without polluting this forum.

How far off is Beta 2 from posting? We are trying to update our products to the released VS 2015 and CodeJock is our last roadblock.Thanks.

We know everyone is anxious for the next Beta, and we have been working hard to address all of the feed back that we have received. We are getting very close and are looking at the week of August 9th for the release of Beta 2.

There is a pretty good probability this will happen. We need to get a BETA 3 released first to make sure immediate issues have been addressed with BETA 2, then if all looks good we are planning on a final release shortly there after.

If not this month definitely the first part of October for sure.

BETA 3 should be ready by next week, we are just wrapping up a few more details before publishing it.

I'm running with the latest Codejock Beta/Visual Studio 2015/Windows 10 configuration. I have an "Aero Lite" theme leftover from Windows updates that seems to work fine when I switch to it. However, none of the Codejock samples run when this theme is active. All samples "freeze" up during initialization when setting the theme for codejock controls. Call Stack looks like:

Stepping through the code it freezes creating a static instance of an "CXTPColorManager". Stepping through a theme that works it's able to set the default theme because the "theme file" path contains "aero.msstyles". Of course the "Aero Lite" theme is in a different msstyles file so it ends up with an xtpSystemThemeUnknown theme. I think this has something to do with it freezing up.

My question: Should it work with themes outside of the Aero.msstyles? Either way it shouldn't lock up like it's doing now. You might already know about this issue. I'm pretty sure people are going to be running with old themes on Windows 10 that are left behind after upgrading.

It seems to be a little bit longer than expected. Have you a new ETA ?

We just posted Beta 3 for download a few days early, we were planning on releasing it this Monday. You will see the download link on the same page as the Toolkit Pro and Suite Pro download link. You will need an active subscription to download Beta 3.

CXTPButton (Radio Buttons not updating)Running Beta 3 I have dialogs with Radio buttons (CXTPButton). I can click a different radio button and the previously checked radio button remains checked until I move the mouse over it. At that time it will refresh and show unchecked.

This allows the user to check down a list of radio buttons and they all appear to be checked. Not good! I can insert a "RedrawWindow" in the click event of every radio button but that shouldn't be necessary.

The "Controls" sample delivered with CodeJock has this same issue. Just click on the radio buttons labeled "Option 1" and "Option 2" and you will see what I mean.

will ASSERT in InitFont() function. It's trying to pull the Codejock font from the resource but it's looking in MY DLL for the resource and fails. I believe it's trying to pull the dropdown triangle symbol out of the font because in release mode I'm not seeing the symbol on the dropdown button. Commenting out the line for now does not get the ASSERT and the combo draws fine with the default theme.

Perhaps a little AFX_MANAGE_STATE(AfxGetStaticModuleState()) is needed??

Also it's still messing with the selected items (the blue) when you add and remove records with grouped / sorted control.

Please note that XAML has been significantly revised starting from 17.0 beta 2, the parser has been completely re-written and made strictly conformant to XML standards, while the previous version allowed incorrect XML syntax in some scenarios. Most likely your issue is one of:

1. there is no space between value of an attribute and the next attribute name, e.g.: Text="Value"Margin="0,0,0,0"

2. If you use XML namespace "x:" now you have to declare this namespace in the root element, global namespace has too be declared too, e.g.:

will ASSERT in InitFont() function. It's trying to pull the Codejock font from the resource but it's looking in MY DLL for the resource and fails. I believe it's trying to pull the dropdown triangle symbol out of the font because in release mode I'm not seeing the symbol on the dropdown button. Commenting out the line for now does not get the ASSERT and the combo draws fine with the default theme.

Perhaps a little AFX_MANAGE_STATE(AfxGetStaticModuleState()) is needed??

Thanks,Derek

Thank you, Derek, for reporting this, however we were unable to reproduce it. It must be depends on on previous actions or theme states, please try to make any of our samples fail in the same way or add necessary modification to it, create a support ticket and upload the sample with instructions.

I built CalendarDemo 64-bit debug with VS 2013, after changing it to use MFC in a static library with the Unicode character set (why isn't Unicode the default?). The build completed with the following error:

I built CalendarDemo 64-bit debug with VS 2013, after changing it to use MFC in a static library with the Unicode character set (why isn't Unicode the default?). The build completed with the following error:

Any idea on a timeframe for the release v17 build? We'd like to make sure there's enough time for us to test before we have another release of our product. Obviously the initial plans have shifted, and that's not a problem, but rough timeframe would be nice. A month from now or even 6 weeks might be doable, but end of the year probably not and we'd have to go ahead and start making contingency plans.

A lot of my flow graphs couldn't be read correctly now with the new microsoft parser. I understand the goal, but what function must be called before setting a caption name to a connection point when a user rename it with a text like that "Caption & Error" ? This must be changed in "Caption &amp; Error" and must be saved in "Caption &amp;amp; Error" to be read correctly next time. Should this function must be called automatically in CXTPFlowGraphControl::RenameConnectionPoint ?

L.

EDIT :

Even if flow graph file is saved in UTF-8 format, the new parser doesn't care and doesn't handle it. All connected point with a caption which contains UTF-8 characters will be skipped.

It's possible to override the default class CXTPFlowGraphEditItem to avoid some problems in edition but some virtual functions are missing like CancelLabelEdit (called from Reposition) in control class.

The integration of JS in markup is nice. I try to activate it in a flow graph, but only one markup context is handled in the flow graph control for all nodes, removing the interest.

Hi, we wanted to give everyone an update on the schedule for 17.0 product release. We are in the final stages of preparing a release candidate for version 17.0. We plan on releasing this by the end of this month. The RC version will be in testing phase for 2 weeks and if no significant issues are reported we will schedule a final release for the third week in December.

Release Candidate for v17 has been published. This will be the last of the betas that we publish prior to the final release version. We are looking to publish the final v17 product release by the end of December.

There is a breaking change in the RC for us: we have CHtmlView derived controls in docking panes and when resizing the pane the whole application freezes.

I remember the same issue before when Internet Explorer 9 was released but it was fixed in v.15.

I have no suitable sample to show you right now, but since it worked in beta 3, perhaps you know what might cause the freezing in the RC? It freezes only if you try to resize a docked docking pane, not if you slide it out and resize it.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum