@ssolie

As I pointed out in my original post the lockup and new method are documented in the latest SDK.

However in previous SDKs there is no mention of the lockup or new method so forgive me for using LAYOUT_AddChild when there was no other way to create dynamic GUIs.

I just wish it had been documented previously as it caused me quite a few headaches.

I apologise if my comment caused offense. It just made me smile that backwards compatibility is the reason for not fixing the original mechanism.

@ssolie

Quote:

Funniest thing I've heard in a long time. So if there's a bug that hangs the OS, it won't get fixed because then it wouldn't be backwards compatible! I'm sure all the major software houses follow the same development methods. Lol

I can appreciate it might take time and effort but remaining backwards compatible to keep the undocumented OS lockup is plain silly.

@trixie

I agree that logically it should be a method not an attribute. Just doesnt make any sense to me to introduce a new way of doing things rather than fix the existing way.

NB Setting attributes on an object calls the method OM_SET so everything is a method anyway.

@Antique

You can use LAYOUT_AddChild to dynamically add gadgets to a window however you run the risk of hanging the OS

In OS 4.1 a method LM_ADDCHILD was introduced which will attempt to add the child gadget.

As to why this new method was introduced rather than fix LAYOUT_AddChild is beyond me

@all

Already got a front end for gdb ;)

From my experience the main issue with gdb is the same as any AmigaOS debugger in that they will place breakpoints in shared code, which can lead to a hang.

You have to be really careful when placing breakpoints or stepping through code. Do not step into system areas and do not place breakpoints in code run under other processes especially input device.

Yes gdb is bloated, arcane and not Amiga OS specific but it does work.

@salass00

Quote:

Agreed APIs change and some methods become obsolete and are therefore deprecated.

It is however entirely idiotic to introduce a new function AbortPkt2 that accepts the same parameters and performs the same functionality as AbortPkt but works correctly.

@ShInKurO

Quote:

It is always good to fix methods that are broken. Causing a system wide lockup I'd say is pretty broken.

It is silly to create new methods that do exactly the same thing and expect programmers to add additional code to use them every time a bug is fixed in the OS.

@All

Autodocs are fine as a format but sadly so much is missing.

@ShInKurO
Quote:

It is possible but you have to subclass the objects and add the support yourself. Which leads back to the problem that some objects cannot be subclassed due to the lack of exposed properties.

@orgin

Quote:

This is what is so silly and messy with Reaction the old methods should have been fixed not introduce new methods.

NB From my understanding, there is no guarantee that the new methods will succeed so the child may or may not be removed / added. i.e. the problem is not fixed. It's just the deadlock is avoided.

Reaction is a v difficult system to work with. It's fine for a simple GUI but trying to do anything complex with it is a nightmare.

1) Dynamic GUI changes cause lock ups. Yes I know there have been some fixes in 4.1 but these lockups can still occur

2) Drag n drop built into objects. Drag and drop is possible but each object requires subclassing atm.

3) It is impossible to subclass some objects due to the lack of exposed properties so effectively you have to write your own gadgets from scratch, increasing development time considerably. Certain OS developers have the opinion that you should not be subclassing system gadgets. Why? No idea seems pretty insane to me

4) Some objects do not support the standard gadget tags but instead implement their own tag that does the same thing. Trial and error makes development time v slow.

5) Documentation is poor. I would like to see self documentating objects i.e. standard properties that return list of all supported tags, descriptions etc.

Oh I could go on forever about how bad Reaction is when compared to other GUI systems.

@HenryCase

UtilityBase was infected by some v nasty trojans.

I believe they have removed the offending code but the site keeps being reinfected.

Until they sort out the CMS system, use it at your own risk.

I highly recommend adding it to the restricted sites lists if you are using IE.

@ssolie

Thx for the info. Sadly, the page gadget is of no use for my purposes.

A lot of the custom objects I have written use a scrollbars property with settings None, Always and Automatic.

The problem setting is Automatic as the objects dynamically add\remove scrollbars depending on the size of their content, which changes as the user interacts with the object.

Users under OS3.X will either have to put up with the lockup (v. rare due to the fudges that are already in place) or use the settings None or Always until I add some more fudges to make the problem go away entirely.

For these objects I have a cunning plan, which removes the need to dynamically add\remove the scrollbar objects and should resolve the issue.

For the GUI designer, worst case will be the need to close and reopen the window as the user adds \ removes objects to it. Won't be pretty but if that's what has to happen under OS3.x so be it.

@ssolie

Weird LM_ADDCHILD works for me with V52.1 of layout gadget

You mention that the deadlock occurs within OM_SET. Is this the only time that the lockup can occur?

Is there a way to detect when intuition will lock up and not call LAYOUT_AddChild in these circumstances? Really thinking of OS 3.x here as this doesn't support LM_ADDCHILD and so I have to use LAYOUT_AddChild.

@Gazelle

Although the SDK docs state V53 i.e. OS4.1, LM_ADDCHILD works under OS4.0 as well.

@orgin

LM_ADDCHILD is a method not an attribute so you have to use DoMethod

struct TagItem NoDisposeTags[] = {CHILD_NoDispose, TRUE, TAG_DONE} ;

if (DoMethod(ParentObj, LM_ADDCHILD, MyWin, ChildObj, NoDisposeTags))
{
// Either call RethinkLayout on ParentObj or DoMethod(WinObj, WM_RETHINK) depends on the type of change
}
else
{
// Ooops object couldn't be added
}

Reason for the NoDisposeTags is so that the object can be added and removed multiple times.

According to the latest SDK for LAYOUT_AddChild -

Do not use this tag to add gadget objects while the layout is in an active Window. An intuition deadlock could result. Use the LM_ADDCHILD method instead.

@All

LAYOUT_AddChild and LAYOUT_RemoveChild work but can cause lockups if the layout is already attached to a window.

Instead use LM_ADDCHILD and LM_REMOVECHILD.

No idea why the OS team added these methods rather than fix the existing methods.

@orgin

Tried to do this myself and have a subclass of listbrowser. Gave up in the end and had to write my own popup class as well.

When I tried I found that PM_Open cannot be called from any callback hooks including WA_MenuHook_- it just locks the OS. You have to use the IDCMP_Flags and trap the RMB.

Guessing here but the reason for the lockup is that PM_Open doesn't return until an item is selected but the OS is waiting for the hook to return before any further messages can be processed.

@spotUP

Not decided on a final name yet but it's basically an up to date development studio for the Amiga.

Screenshots of Beta 0.1 are at

http://www.amigans.net/modules/myalbum/photo.php?lid=200

Quite old but most of what you can see there is pretty much the same in the current version. Just a lot more features and quite a few bug fixes now that the SDK docs are available!

Might upload a vid at some point so that it catches the autocomplete and popup windows. srec catches them nicely.

Feature list

Project management - hard coded for C and Modula2 projects at the moment. Other project types can be used but the project management side of things will not maintain the build file. Examples needed!

Multi document editor with syntax highlighting. Syntax highlighting is externally driven via XML so you can define syntaxes for pretty much any language you like. C/C++ (with complete syntaxes for the SDK includes), Modula2, SQL syntaxes, amigaguide, etc. are included.

Integrated help, popup hints and autocomplete. Driven by the same syntax files. The parser is reasonably smart so can work out variable types etc. and present a shortened list for autocomplete. Help Links to autodocs, includes, amigaguides, etc. are supported. All help documents are cross indexed.

Fully redefinable keyboard with over 100 built in commands + macro support. Usual editor commands + loads of commands for coders - indent, group (fold), toupper/lower, move to brace/bracket, (un)comment, etc.

Compiler support for GCC, VBCC and M2Err (Modula2). Compilation is a seperate process so you can look into the warnings \ errors as the compilation continues. Other compilers are pretty simple to support.

Bookmarks - Note, Warning, Error, Breakpoint types are supported with multiple bookmarks per line. Warnings and error bookmarks are automatically created during the compilation process. Breakpoint bookmarks are used by the debugger. Notes are user definable. In all cases hovering over the bookmark in the editor displays the associated comment \ comments.

Unicode support - experimental. Really need Hyperion to add support within the OS.

GUI Driven Debugger- start, continue, step, step over, step into, add \ remove breakpoint, watches, variable browser (editable where possible). You have to be really careful with this as a breakpoint in the wrong place will kill the OS.

Probably lots of things I've forgotten about that may end up in Beta 0.3.

@orgin

There isn't much documentation available. The SDK documents all the classes and provides a few simple examples of how to use reaction objects. What it still doesn't do is tell you which of the base class attributes are overridden \ supported so that's just trial an error.

The RKMs have details of how gadgetclass, imageclass, icclass etc. work and provide examples but don't document the additional methods\attributes that Reaction provides.

If you are writing classes (not for the faint hearted), you will need to read gadget_gc.doc (now included in the SDK autodocs).

I'd also recommend reading the MUI documentation - MUI and Reaction are pretty much the same thing and work in pretty much the same way.

@Swoop

Quote:

Can't get MPlayer to play them directly as it crashes but when played via FFMPegGUI using MPlayer it works :)

Thx

@salass00

Quote:

Explains why I can't get anything to play the files. What program Amiga or otherwise can play them or convert them to something playable?