If your demo app needs more stack for whatever the reason, the way to do it is to set the stack in the app's code itself: by using

Code:

but if it's the mcc that needs such a huge amount of stack, you will need to swap the stack in the entry points to your mcc - could likely be done in a smart way just by modifying the dispatcher.

Either way, this is a bug that's on you to fix.

[ Edited by jacadcaps On 2018/9/17 15:49 ]

Quote:

It's no bug, is's cairo and a huge render surface...
I must include a seperate render process in my class (if i have free time...)
There i can adjust the stack for the process very easy

Quote:

Is there some recursive function call? Or is there some huge statically allocated array somewhere (be it in global scope (https://www.learncpp.com/cpp-tutorial/4-2a-why-global-variables-are-evil/) or in function prolog)?

Already used Cairo library and I didn't had the need to extend the stack to insane values to make it work.

Anyway, always nice to see new stuff.

++

Quote:

It's OK for static displays. But a little bit of confusing for dynamic displays with huge amount of grapic updates.
Cairo needs the stack for buffer his graphic calls. So i must see, if i find a cairo fuction to delete this stack buffer.

Ok A much better version: rtf.mcc 1.10
The class render his contents in a separate process and the renderer flushs the comand stack of cairo.
The result did't crash on my computer now.

Carsten, I too like the idea of having the ability to view/save RTF documents with MorphOS, . . . but . . . these versions just don't seem to even load the "RTF-Riddle-User" Demo RTF documents you've included with the archive, never mind any RTF documents that I currently have of my own.

The input gadget that shows the "Tile" ( .... shouldn't that actually read "Title"?) is at the bottom of the GUI, and would that not be better positioned at the top of the GUI, where the Title, Subject, Author, are supposed to load into, and hopefully also be editable?

Also, if you've allowed for an input gadget, would it not also be good to have a menu option to Load and Save/As as well, with keyboard shortcuts?

The GUI window is not fully re-sizeable, and only allows the window to open to about half the width of my screen, which makes it very limiting, that's before you implement anything else, as such features are intrinsic to being able to use it better, and is worthy of mentioning while you are getting the basics fixed.

I know this is probably supposed to be a Beta or something like that, so my previous suggestions may still to be implemented in a later date release, but would it not be better to get more users to test it before you release anything like this in such a poor state and subsequently get other users to ignore your hardwork in the future, as they may expect it to be yet another release that is unuseable.

I feel sure there are other people on the Development Team, or other BetaTesters, that you could ask for a little advice, and for them to give you some reaction/guidance before you release it, when necessary, to improve your releases to better success in the future.

I'd like this idea to succeed, but sadly it's not off to a great start at the moment.

By the way . . .

Quote:
What's happened to that idea? By the way . . . the word is spelled "Spreadsheet"
Quote:
What's happened to more up-to-date, or any future releases for that idea/program as well?

[ Edited by NewSense On 2018/9/19 6:46 ]

The prog is only a demo for my MUI class. And the Stringgadget on the bottom is from an other project
Without any function. It's a DEMO. Important is the rtf.mcc. Thats support many key tags of the RTF Format.

Please don't judge about the prog






Quote:

Quote:

Problem. People judge by what they see and feel.

Make it nice. Add an icon, a guide (even a simple readme can be enough for really simple apps), make the app localized, create a lha archive that produce a directory (and not simply drop all the files where you uncompress the thing), stick to style guide (menu, buttons, shortcuts, settings with use/save/cancel, etc...).

For the window resize, seriously... This is where your statically allocated buffer kicks in or?

You're using Cairo... a vector to raster renderer. What's the point in using a fixed size rendering area?

Anyway. Nice to see new stuff. Keep on and improve your products.

Cheers

I can't add a Icon to a MUI class ! And i can't add a guide, too.
I develope extern MUI Classes since 1 year. The test app to load my class is nearly the same by all classes.
YOU can develope a nice Doc reader or any kind of viewer, if you wish.
I develope nice MUI classes now !
And the next one is on the road..

What's the point in using a fixed size rendering area? ?? It's not fixed... Take a look into the demo sources.
You can resize the class on every direction, if you develope this. The Init Attributes for width and heigth are the min.
dimensions of the class.





Quote:

Quote:

Sure. I was talking about your demo app.

Quote:

Hu? And why that? MCC should have proper documentation for being used by others...

Quote:

Hu. That's not how things are supposed to work in MUI. What if the min width or min height are larger than available screen estate? The component will fail to layout... Technically, there is no reason to have such init attributes imo. The component should let MUI do the layout job with whatever screen estate is available and render inside the _mwidth(obj)/_mheight(obj).

You should give a look at how APDF is working for displaying documents.

Also, as a side note, you better provide a library (and not a MUI class) that could render in a rastport for example. That way one could pick the rastport content without messing with MUI.

The MCC could now do calls to the library and do all the dirty UI stuff required for displaying the document.

You're mixing UI stuff with processing stuff which is IMO not very wise: it is like providing cairo.library API from a MUI class...