WP8/XAML-以像素为单位测量字符串长度 [英] WP8/XAML - Measure string length in pixels

问题描述

像素长度测量代码，如下所示:

Pixel-length measuring code, like this one:

public int TextWidth(string text)
    {
        TextBlock t = new TextBlock();
        t.Text = text;
        t.Measure(new Size(1000, 1000));
        return (int)t.DesiredSize.Width;
    }

不起作用(结果为0)，因为它需要显示TextBlock(不需要可见性)，因此它需要与gui线程联系，这很糟糕. 它已经是非常丑陋的代码，任何进一步的膨胀都会让我呕吐，一想到使用它就可以.

Is not working (result is 0) because it requires TextBlock to be displayed (visibility is not required), so it would require contact with gui thread, which is bad. It is already very ugly code, and any further bloating will make me vomit at sole thought of using it.

Graphics.MeasureString()在WP平台上不可用.

Graphics.MeasureString() is not available on WP platform.

那么...有什么人道方法可以做到这一点? 解决方案不需要与WP7向后兼容，它甚至可以是C ++代码，因为它是我需要文本长度的运行时组件中的代码，因此ti甚至可以避免某些本机管理的本地计算时间的跳跃.

So... is there any humanitarian way to do it? Solution is not required to be backward compatible with WP7, it even might be C++ code as it is in Runtime Component where I need text length, so ti would even shave off some native-managed-native computing time gobbling jumps.

还是最后我做错了方法?

Or maybe in the end I am making wrong approach?

我在WriteableBitmap上呈现了TextBlock，它要求采用最小尺寸，但仍可容纳整个文本. 即使已知位图可以占用的最大大小(屏幕分辨率或父级大小)，根据设备屏幕的不同，在最坏的情况下，一张位图仍会占用1MB至7MB的内存.预计同时使用约30篇文章，这将是谋杀案. 因此，这种方法最终更加难看.

I have TextBlock rendered on WriteableBitmap which is required to take on minimal size that can still fit whole text. Even with known max size that bitmap can take (screen resolution or parent size) it will still take up, depending on device screen, from 1MB to 7MB just for one bitmap at worst case. Which with predicted ~30 texts used in same time will be memory murdering. So this approach is even uglier in the end.

(Rendered目前在XAML应用程序中与WriteableBitmaps结合在一起，并且在运行时组件中放置了逻辑，这是可悲的图像，最后，我计划将渲染模块替换为DirectX，但现在它需要以可接受的速度工作，并专注于重要应用逻辑，因为第一个版本的截止日期即将结束

(Rendered is currently pathetic Image bobmarded with WriteableBitmaps in XAML app with logic placed in Runtime Component, in the end I plan to replace rendering module with DirectX, but for now it needs to just work with some acceptable speed and focus on important part in, app logic, as deadline for first version is closing in)

推荐答案

在WP8设备上运行的解决方案(在HTC 8S和Lumia 920上进行了测试)

Solution working on WP8 device (tested on HTC 8S and Lumia 920)

    public int TextWidth(string text)
    {
        TextBlock t = new TextBlock();
        t.Text = text;
        //Height and Width are depending on font settings
        //t.FontFaimily=...
        //t.FontSize=...
        //etc.
        return (int)Math.Ceiling(t.ActualWidth);
    }

根据我发现的所有信息，在测量和排列控件之前，不应该设置ActualWidth，但是在DesiredSize返回0的情况下，无论测量还是排列控件，即使在静态添加到窗体时，ActualWidth都可以正常工作.可用材料中没有描述.

According to all information I found, ActualWidth should not be set until control is measured and arranged, but somehow it works while DesiredSize returned 0's for controls both measured and arranged, even ones statically added to form. Which is not as described in available materials.

该解决方案仍然很难看，如果我正确理解，那么如果设备dpi不是96时，将无法给出正确的数字，因为ActualWidht/Height值是1/96的与设备无关的单位".但是就目前而言，如果我没记错的话，所有WP8设备都可以在旧的96dpi上工作，因此直到找到或提供实际的解决方案为止(例如台式机.NET Graphics.MeasureString())，它都可以充当代理.

This solution is still rather ugly one and, if I understood correctly, will fail to give correct number if device dpi is other than 96 as ActualWidht/Height value is in "device-independent unit" of 1/96. But for now, if I am not mistaken, all WP8 devices work in ye old 96dpi so until real solution will be found or made available (like desktop .NET Graphics.MeasureString()) it can act as surrogate.

有关MSDN的信息ActualWidth .

这篇关于WP8/XAML-以像素为单位测量字符串长度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！