Who's Online |
58 user(s) are online ( 39 user(s) are browsing Forums)
Members: 0
Guests: 58
more...
|
|
|
|
|
Re: Post-Update 6 updates
|
Posted on: 2013/2/13 20:16
#101
|
Just popping in 
|
Quote: Hmm... does that mean we can set different pointer styles now using SetWindowPointer(), rather than titting about creating new pointerclass objects? Yes. Not really styles, but standardized pointer images. For example your application calls SetWindowPointer(win, WA_PointerType, POINTERTYPE_HAND, TAG_DONE) and the user will see the well known "pointing hand" pointer image as used by browser applications on other systems when the mouse hovers over a hyperlink.
|
|
|
|
|
|
Re: I.... hate AmiDock...!
|
Posted on: 2013/2/8 9:30
#102
|
Just popping in
|
Quote: YAM also uses AmiDock (I think) and its source code is available on SourceForge, but I agree that AmiDock is pretty rubbish, having tried to write docky code myself. Yes, but YAM is using a simple icon only to indicate its current state about new mails, downloading mails, etc. But YAM is not using a custom context menu.
|
|
|
|
|
|
Re: giu.prefs
|
Posted on: 2013/1/29 7:47
#103
|
Just popping in
|
Refer to the include file prefs/gui.h. All you need is defined there.
|
|
|
|
|
|
Re: File requesters open on WB not on custom screen
|
Posted on: 2013/1/27 12:04
#104
|
Just popping in
|
The next update will open all ASL requesters on the application's screen.
|
|
|
|
|
|
Re: MUI : is it possible to resize window programmatically ?
|
Posted on: 2013/1/14 13:23
#105
|
Just popping in
|
Quote: I will try it this evening by specifying fixed size. This will most probably not archive the result you are intending, because MUIA_Window_Width/Height represents either a pixel or a percentage (of the screen's dimension) value. Enforcing a fixed pixel width is an absolute no-go for font sensitive GUIs. And enforcing a fixed percentage of the screen dimensions is equally bad if there is really not that much content in some parts of the GUI.
|
|
|
|
|
|
Re: MUI : is it possible to resize window programmatically ?
|
Posted on: 2013/1/14 8:24
#106
|
Just popping in
|
Quote: Is it possible to resize a MUI window by code in C ? Short answer: no Long answer: no, because this absolutely contradicts the basic MUI philosophy of letting the user choose the GUI size. Even if you think that a part of the GUI is too "small" compared to other parts this is only your opinion. Others might think different. And having a constantly self-resizing window is quite annoying. Even if MUI will resize windows sometimes this will only be done if this is really absolutely necessary to layout all objects with their minimum required size. Quote: For example, my program SysMon consists of a RegisterGroup with many tabs.
When a tab is opened, the window is scaled depending of the gadget inside the tab.
Normal.
But when I go to another tab who is littler, the window is not resized and keep the previous big size. Then you better restructure the GUI to make both pages more similar and hence use a similar amount of space. However, with MUI4 (and probably with the next update of MUI 3.9 already) it will be possible to force virtual groups to a specific size using the MUIA_Virtgroup_TryFit attribute while still allowing the GUI to be resizeable. But I really doubt this will be the thing you are looking for.
|
|
|
|
|
|
Re: Tabbing away from a MUI String gadget - any way to get an event?
|
Posted on: 2012/12/21 17:47
#107
|
Just popping in
|
Quote: MUIM_GoInactive does not exist in my public MUI headers. Since this solution is suppose to work on OS3.x (and clones), I guess this means your solution isn't workable  I may be missing in the by now quite old MUI 3.8 includes, but it is available in MUI 3.8 already and public since MUI 3.9. Furthermore there is the undocumented MUI features archive on Aminet since more than 14 years by now. This archives contains a header file with lots of useful definitions.
|
|
|
|
|
|
Re: Tabbing away from a MUI String gadget - any way to get an event?
|
Posted on: 2012/12/19 21:50
#108
|
Just popping in
|
There is no other way than subclassing. Just watch out for MUIM_GoInactive. This method will be called whenever the active object becomes inactive for whatever reason: TAB, mouse click, etc.
|
|
|
|
|
|
Re: Use of Glow icon as Picture in a MUI program
|
Posted on: 2012/11/5 9:22
#109
|
Just popping in
|
Quote: But in AboutBox which method do you use ?
GetIconTags, LayoutIcon, IconControl
followed by an
ImageObject, MUIA_Image_OldImage
or another method ? Icons are loaded with GetIconTags() and drawn with DrawIconState(). All this is encapsulated in a private subclass of Area.mui.
|
|
|
|
|
|
Re: Use of Glow icon as Picture in a MUI program
|
Posted on: 2012/11/4 19:04
#110
|
Just popping in
|
Quote: 1) I'm trying to use a Glow icon as source of a DTPic picture in a program but it fails to show. That can only work if you have a suitable datatype for Glow icons installed. Hence the appropriate name "Dtpic". Quote: But in the AboutBox (AboutBox MUI class) the glow icon is well showed ! This works, because the icon as accessed as exactly this: an icon, not an arbitrary image file to be loaded via datatypes.library.
|
|
|
|
|
|
Re: c++ and stabs (db101)
|
Posted on: 2012/10/12 11:14
#111
|
Just popping in
|
Quote: I have built a Qt example (Calculator) with -gstabs in the command line, and now I want to read the stabs section with db101. Did you compile with -gstabs only or with -g and -gstabs? At least for YAM we are building with both options and objdump will output tons of debug information.
|
|
|
|
|
|
Re: Ask help for MUIA_Application_Version and Version command
|
Posted on: 2012/10/4 12:40
#112
|
Just popping in
|
Quote: For the AboutBox, I tried to use the built-in %t or %p but it was not localized, all was in english, The french translation has not yet been updated, but that is nothing to worry about. That's all. Just be patient.
|
|
|
|
|
|
Re: Ask help for MUIA_Application_Version and Version command
|
Posted on: 2012/10/4 2:25
#113
|
Just popping in
|
@zzd10h
1. Never use localized dates in version strings. The Version command will take care to convert the date accoring to your locale settings. The date format in version strings is fixed to "day.month.year", numbers only.
2. C:Version will only extract the string after the "$VER:" cookie from the program file. It cannot output strings that are built during the program's execution. Exchange will obtain the version string from the running application and hence show the string the application might have dynamically built at runtime.
3. Don't use non-length limiting string functions like sprintf/strcpy/strcat. Use snprintf/strlcpy/strlcat all the time instead, even if you know the final string will fit into the supplied buffer. This will save you a lot of hassle later on.
4. Don't use escape sequences of MUI's text engine in version strings. Only MUI knows how to handle them correctly. Other applications might become confused and may fail to output such a version string correctly.
5. Since you use Aboutbox.mcc, why do you reinvent the wheel and provide a complete own credits text instead of using Aboutbox.mcc's built in feature to replace placeholders like "%l" and "%t" by standardized texts like "Translations:" or "Thanks to:"?
|
|
|
|
|
|
Re: Integer in source code
|
Posted on: 2012/9/17 18:57
#114
|
Just popping in
|
Usually it should be 32 bits wide and hence take 4 bytes.
Use something like "printf("%d\n", sizeof(int));" to be really sure. Types like "int" or "short" are very system specific and their size may vary between different platforms.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Memory Page Locking Confusion
|
Posted on: 2012/9/4 11:28
#115
|
Just popping in
|
Quote: Why on earth is executable memory locked for 68k backward compatibility when only PPC code is executable??! Seems like a complete waste of locked memory. This means that when monster apps like MPlayer, OWB and TW crashes or hangs (mostly hangs) the system can't swap out the large chunk of executable code. Task switching is still done in an interrupt. If the new task's code is currently swapped out the scheduler would have to wait for the pages to be swapped in again. But waiting for an arbitrary long time is not possible in an interrupt and you cannot tell how long the low lever hard disk driver will need to perform the swap in job. Thus executeable code must be accessible at any time and hence must be locked to prevent it from being swapped out.
|
|
|
|
|
|
Re: YAM's strobing editor
|
Posted on: 2012/8/28 16:02
#116
|
Just popping in
|
@xenic Quote: Update5 muimaster.library is v20.2344 (07/29/2012) - Size 850344
Yam flickering with that library. Congratulations. You found a real bug in MUI 3.9 of update #5! After having typed really fast in YAM's text editor by banging my head, feet and hands onto the keyboard I was finally able to reproduce and notice the flickering. I then compared all source files another time finally found the true cause for the flicker effect. The editor in YAM's write window has a two line cursor position display in the upper right corner. During the preparations for update #5 it was reported that setting a new text containing more lines than the old one caused MUI to draw outside the object's area. This was fixed by checking whether there are LF characters in the text or not. If yes, then a relayout of the surrounding group was triggered to make MUI recalculate the required area to display all text. This might cause some flickering depending on the complexity of the group due to the necessary redraw actions. Unfortunately this check did not include the case that the new text contains exactly the same amount of lines as the old one and thus a relayout is not required at all. Instead MUI triggered a relayout everytime resulting in the noticed flicker effect. This will be fixed in the next release. I cannot tell if something like update #6 is planned at all, so please be patient. But thanks a lot for insisting on having spotted a bug, even if I rejected it in the first place.
|
|
|
|
|
|
Re: YAM's strobing editor
|
Posted on: 2012/8/28 5:31
#117
|
Just popping in
|
Quote: EDIT: That didn't take long. When I replaced the Update5 muimaster.library with my previous muimaster.library, the flickering disappeared (after a reboot).
Update5 muimaster.library is v20.2344 (07/29/2012) - Size 850344
Yam flickering with that library.
Old muimaster.library is v20.2336 (11/26/2011) - Size 800220
Yam not flickering with old library. I just compared the source of both MUI releases. 98% of all differences is either the bumped revision or the allocation scheme of MEMF_SHARED memory to not lock the memory pages. There are no changes in the graphics department and the only class with some larger changes is the list class, which has absolutely nothing to do with TextEditor.mcc. So from my point of view there is nothing wrong or fixable, since there is no change which could really explain this behaviour.
|
|
|
|
|
|
Re: YAM's strobing editor
|
Posted on: 2012/8/27 19:05
#118
|
Just popping in
|
@xenic I just tried to reproduce this issue myself, and guess what: it does not flicker at all for me. So from my point of view the flicker effect can only be caused by your personal settings. Could you please send me your global MUI configuration file privately, or the YAM specific configuration file if your are using even more custom settings for YAM? Quote: The MUI files in OS4.1update5 are making YAM look pretty bad for some of us. It might be more obvious on certain hardware but I think enough people have confirmed the problem to warrant a look into the issue by someone who can do something about it. Well, you name it: for some of us, but not for all. MUI's most important feature is the ability to be able to configure each and everything. Unfortunately this requires a valid key file. I am really sorry, but until now we are not allowed to remove this restriction and to let everybody configure MUI to his/her personal gusto. Thus the built in default settings have to be enough. However, if there is a setting that I can tweak to make a certain application looking better when using the default settings without breaking all others then please tell me.
|
|
|
|
|
|
Re: YAM's flashing editor
|
Posted on: 2012/8/27 18:57
#119
|
Just popping in
|
There is already a bug report on sf.net. The main problem is that TextEditor.mcc does its best to misobey the most basic rules of MUI programming and that it is a real PITA to fix this. Until this is done there is only one solution, namely to use a plain color background.
|
|
|
|
|
|
Re: YAM's strobing editor
|
Posted on: 2012/8/27 11:04
#120
|
Just popping in
|
Quote: This was something completely different.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
