Our oBaseVisComponent should get a new property that we apply to all drawing functions called pScale.

This should enlarge how we render things but without our subclassed component needing to worry about this scale factor.

This would be handy for creating the ability for the user to zoom in on the component, to render to bitmap at a higher resolution, or potentially some day add retina support.

Need to look into creating a makefile that would compile the library into a static library so we do not have to include the entire source in our projects.

The way oDataList is currently implemented means that we need to recalculate the positioning of fields whenever the source list changes. When using an item reference we can't adequately determine this and we end up recalculating way to much data each time Omnis gives us a new copy of the reference.

I either need to find a better way of detecting something has changed or make our vertical scroll line based instead of pixel based so I only need to calculate positioning and sizing information for the lines shown on screen (as that is where the bulk of the performance penalty lies).

Right now our drawing functions are methods of our visual component, but that does hinder us somewhat.

Looking into making a separate drawing context object that has these methods, the HDC to use, the clip stack, etc.

This would also make it easier to implement drawing to a bitmap where we need to do so.

Add a function to our standard visual component that will render our component into a bitmap, potentially irrespective of the size of the component on screen as well as nominating a specific area to render.

This would be especially important for components that cover a large area where we have scroll bars and we want to print the contents. We may need to render each part of the full area in bits and print them over multiple pages (think of things like spreadsheets or graphs).

So the call will be something like:
HBITMAP oBaseVisComponent(qrect pScreen, qrect pRender);

Where pScreen is the rectangle defining our total "screen" are while pRender defines the rectangle within that we'll actually render onto our bitmap.

As we've implemented our own wrapping text code the new line is drawing in the default style again. We need to find a way to determine more about the style and repeat it.

DrawTextJst seems to have an issue with not adhering to the clipping rectangle, especially the vertical boundary.

We may not have any influence on this as this is handled within the SDK, we'll need to look into this further.

Hejhej Bastiaan,
Just a small remark on the link to the SDK. It is outdated and I think you want it to link to the page below or not?
https://omnis.net/documentation/extcompsdk/index.jsp

grtz

The std::vector template class that is part of C++ standard classes does a much better job than qArray. Time to retire it.

Need to look into changing this code to returning qchar& instead of qchar*

Changing XCode project files to work with XCode 6.

The biggest issue here is that XCode 6 no longer contains the 1.6 SDK that the Omnis SDK relies on. It has to be copied from XCode 4 into XCode 6 before we can compile.

After that it is a matter of updating the project files and looking into compiler issues.