How i can get window border sizes given screen. Applies All amigaos and morphos. Amiga ROM Kernel Reference Manual Libraries Third edition gives how top borner is solved in AmigAOS2.0. Is possible get i understabnd correctly opening Screen with OpenScreenTags return value "Screen" or even workbench screen if i give correct screen structure (how i get it for Workbench/Ambient screen?) Screen->WBarBottom for example when i want know given screen winow bottom border thinkness etc. why i need such info to open perfect size windows of course. I know MUI and very likely Reaction also makes perfect size windows when i use their API but if i want window with graphics what they dont give i dont say better but all coders should know what i mean if not for example windows which shows bitmaps or window where i draw anything without using gui functions. And over thinking what others code is silly..) (trust me i almost know what i do).

Last edited by Vanhapolle on 21-Dec-2014 at 09:44 PM.

@Vanhapolle

If I understand you correctly you want to know the border sizes so you can calculate the correct sized window for your content?

Well you can probably extract them from the screen structure as you said, but the better way would ofcourse be to use the right OpenWindow tags.

Try using WA_InnerWidth and WA_InnerHeight when opening your window. These are intuition tags so will work with ordinary windows not just window.class ones.

BTW LockPubscreen(NULL) will get you the Workbench screens screen structure (more accurately the default public screen, which most of the time is workbench).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Thanks. but how i can get just for Workbench not default public screen looks at least 2.0 time using screen name is solution if understand correctly. and WA_InnerWidth etc sounds nicer even reducing all possible calculations makes code easier do. Even more when i dont care much before 2.0 AOS versions. Simply becouse coding form them is to my eyes very paintful. I like Taglist way opening Screens not old Structure way. And very likely they are rarely sed anything serious. Actually i little dislike structures even i understand their point.

Window.class you mean something which is Reaction related?

Noe offtopic: even Reaction is changed for AmigaOS4.1 understanded when i look its documentation i must also maybe test with AmigaOS3.9 it. Looks maybe nicer than what i imagined earlier. I think i now understand reason different things code than earlier. I maybe print this day OS3.9 NDK Reaction examples. and try look them and documentation if can do even gui with Reaction with OS3.9 after this.:) OS4.1 reaction way is somehow i understanded changed which needs learining another thing.

Last edited by Vanhapolle on 21-Dec-2014 at 10:44 PM.
Last edited by Vanhapolle on 21-Dec-2014 at 10:39 PM.
Last edited by Vanhapolle on 21-Dec-2014 at 10:34 PM.
Last edited by Vanhapolle on 21-Dec-2014 at 10:23 PM.

@Vanhapolle

Quote:

Thanks. but how i can get just for Workbench not default public screen looks at least 2.0 time using screen name is solution if understand correctly.

Yes using the name "Workbench" will get it for you explicitly but if it's been replaced by DOPus or something it may not be there, which is why NULL may be more useful.

Quote:

Even more when i dont care much before 2.0 AOS versions. Simply becouse coding form them is to my eyes very paintful.

Unless you have some reason to support 2.04 I would make 3.1 your baseline.

Quote:

Window.class you mean something which is Reaction related?

window.class is the BOOPSI/REACTION high level window yes.

Quote:

oe offtopic: even Reaction is changed for AmigaOS4.1 understanded when i look its documentation i must also maybe test with AmigaOS3.9 it. Looks maybe nicer than what i imagined earlier. I think i now understand reason different things code than earlier. I maybe print this day OS3.9 NDK Reaction examples. and try look them and documentation if can do even gui with Reaction with OS3.9 after this.:) OS4.1 reaction way is somehow i understanded changed which needs learining another thing.

Generally code for 3,9 Reaction should be upwardly compatble with 4.1 reaction, less like the other way round as 4.1 has many new featues and fixes and more gadget types.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

This means i can maybe even compile directly OS3.9 source which dont use audio.device and trackdisk.device to OS4.1?
ps. absotely 3.0 is my baseline expect things what need 3.1. most of ideas anyway need...

@broadblues

Quote:

Yes using the name "Workbench" will get it for you explicitly but if it's been replaced by DOPus or something it may not be there, which is why NULL may be more useful.

You always have the "Workbench" screen available in DOpus, Scalos, Ambient and Wanderer.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Vanhapolle

Quote:

Vanhapolle wrote: how i can get just for Workbench not default public screen looks at least 2.0 time using screen name is solution if understand correctly.

Forcing a window to Workbench is bad coding style. If Workbench is not the default public screen, then the user has configured it like this for a reason. If you force your window to Workbench anyway, you work against this choice. For this reason your software will hardly be accepted.

Actually you should make the public screen name configurable and if the user did not configure a name, you should use the default.

_________________
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de

Some things are need workbench screen but generally its bad idea i know.
Now i maybe soon test new printing paper.:) which means i try print now Reaction examples for OS3.9.

@Vanhapolle

Quote:

Vanhapolle wrote: This means i can maybe even compile directly OS3.9 source which dont use audio.device and trackdisk.device to OS4.1?

No idea about compiling but audio.device should work with no problems. and trackdisk.device if you make allowance for emulated drives. eg. do not set it specifically for DFx:, HFx:, PCx: etc. allow the user to use mounted adf files via IDFx: IHFx: IPCx: etc. should work. Better just avoid trackdisk.device as much as possible.

If you're dealing with anything that shows or uses filesizes don't forget to make your variables 64bit and allow bigger buffers for path & filename if you want OS4.x compatability.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@Vanhapolle

Quote:

This means i can maybe even compile directly OS3.9 source which dont use audio.device and trackdisk.device to OS4.1?

Well you can compile it if does or does not use trackdisk.device, I don't belive audio.device is a problem for AmigaOS4, the problem is ciaa.resource and ciab.resource. And hardware addresses to hardware that does not exist on AmigaOS4.

The C compiler does not check if hardware or OS libraries, devices and resources exists or not.

If you coding includes stuff that AmigaOS4.1 no longer support then it wont work on AmigaOS4.1, but that does not stop you from compiling it and running under EUAE or copying it to Classic Amiga.

Supporting icon tooltypes so people can change the name from trackdisk.device to what ever they like helps a lot, if is some low level software.

On AmigaOS4.1 you have rad.device, diskImage.device , cw.device, a1floppy.device and few other devices, hard coding to trackdisk.device is a bad idea.

Quote:

ps. absotely 3.0 is my baseline expect things what need 3.1. most of ideas anyway need...

Actually if your software has anything with HD drives and disk, your baseline should be AmigaOS3.5 with NSDPatch, if its a simple program that is not going to handle large files or large partitions, you can even support AmigaOS1.2, I have software that needs Workbench/Kickstart1.2 that runs on AmigaOS4.1.

The problem is that you need to design your software using Gadtools. No Reaction or MUI (too freaking big) .

Last edited by NutsAboutAmiga on 22-Dec-2014 at 02:43 PM.
Last edited by NutsAboutAmiga on 22-Dec-2014 at 02:41 PM.
Last edited by NutsAboutAmiga on 22-Dec-2014 at 02:37 PM.
Last edited by NutsAboutAmiga on 22-Dec-2014 at 02:36 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@broadblues

Quote:

Try using WA_InnerWidth and WA_InnerHeight when opening your window.

I thought these looked useful when I found them, but I also thought they were a tad incomplete. For example what if you want to centre a window? AFAIK no tags for 68K allowed to do that. So a query function would have been useful to get border sizes for a window.

@Vanhapolle

Quote:

This means i can maybe even compile directly OS3.9 source which dont use audio.device and trackdisk.device to OS4.1?

That would be better. But then you'd need AHI for audio.

What would the trackdisk.device be needed for in the code? That's fairly direct and sounds like it's tied to 68K. OS4 does have the a1floppy.device that works the same at a basic level but hard coding to a device like this is a bad idea. The device and unit of of a drive shoukd be grabbed from a DOS handle or volume chosen by the user which is easier on them.

@Hypex

Quote:

The device and unit of of a drive shoukd be grabbed from a DOS handle or volume chosen by the user which is easier on them.

The device and unit of a drive is pretty much irrelevent if you are just doing file access. That's what the filesystem is for.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Hypex

Quote:

I thought these looked useful when I found them, but I also thought they were a tad incomplete. For example what if you want to centre a window? AFAIK no tags for 68K allowed to do that. So a query function would have been useful to get border sizes for a window.

Last time I checked Reaction / ClassAct under AmigaOS 3.x were 68k and both contained the WINDOW_Position tag.

If you needed to calculate by hand for aplain intuintion window you can use the following readonly fields of the screen structure.

[/quote]
*
* Also, the title bar height of a window is calculated from the
* screen's WBorTop field, plus the font height, plus one.
*/
BYTE BarHeight, BarVBorder, BarHBorder, MenuVBorder, MenuHBorder;
BYTE WBorTop, WBorLeft, WBorRight, WBorBottom;
[/quote]

I think you would still use those for an OS4 plain intuition Window. Hoever the need to use plain windows is somewhat reduced on the more modern versions of the OS as window.class has more features. For example I'm sure AWeb could use window class throught out if it were written from scratch for AmogaOS4, whereas it needed to a plain tuition window for it main browser winodw due to input handling limitations.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

The device and unit of a drive is pretty much irrelevent if you are just doing file access.

Given the original code used trackdisk.device implied it was going deeper than the usual file access.

Quote:

Last time I checked Reaction / ClassAct under AmigaOS 3.x were 68k and both contained the WINDOW_Position tag

I was looking up standard Intuition docs but the above wouldn't work with OpenWindowTags() would it? That's what I was using.

Quote:

I think you would still use those for an OS4 plain intuition Window

I do use those borders. But it would be good to pass some tags tot he OS and avoid reading them directly. For example I wrote a mini-layout engine for Gadtools that calculated inner width and height and it would have been good to let the OS figure out the border size itself and centre it.