Re: How to reorder lines in a list field

[Wilhelm Sanke]

Check out



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: The power of despeckle-median filters: Image examples

[Wilhelm Sanke]

Providing feedback in this thread, some list members have expressed 
their appreciation for discussed image-processing approaches and 
scripts, along with the proposal to present such topics in greater 
detail in a RunRev newsletter article. Alejandro Tejada wrote:


"They should publish an extensive review
of your scripts and how you port Lua
scripts to Rev."

while Kevin Miller added to this without specifying a special topic

"if you might be
interested in doing a newsletter article then please drop me a line off
list".

As I am unsure what the focus of an article should be and because there 
is a wide range of possible topics for image processing, I will list 
some of such topics and present a proposal - as a primary option - for a 
possible (first) newsletter article on image-processing in Revolution. 
Of course, I will contact Kevin about this also off-list.


Concerning "Lua" in Revolution I see three options:

1. Rewriting my post of  March 3 "Language comparisons: "Lua" - simpler 
and faster than
RevTalk", which already discusses in some detail several syntax formats 
for image processing in Revolution and pointing out the crucial 
similarities and differences between RevTalk and Lua. This could be 
accompanied by more examples and a sample stack.


2. Focusing on Lua-to-RevTalk conversions with a sample stack containing 
about 25 Lua scripts ported to RevTalk and including some extra variants 
developed on the basis of these Lua scripts. Article and sample stack 
would allow side-by-side comparisons of Lua and RevTalk versions. The 
sample stack is almost ready to be released.


3. Focusing on using Lua embedded in Revolution.  I am authorized to 
mention that we will soon have the possibility to run Lua scripts 
directly in Revolution as an outcome of a collaborative project. I 
consider this to be a huge step forward for image procession with 
Revolution. The power and enormous speed of Lua will join and enhance 
the potential of Revolution.


This would be my first option. We should ask the person mainly 
responsible for developing the Lua add-ons to write an introductory 
article on how to integrate Lua in Revolution and how to use the 
accompanying sample stacks and tutorials.


These Lua tools for Revolution will be released in the very near future, 
so please refrain from asking questions about this now.--


I will now list here a number of - not Lua related - aspects of image 
processing in Revolution that demonstrate that there is a wide variety 
of possible topics, each of which would deserve a separate newsletter 
article. Each of these topics could be accompanied by sample stacks - 
some of which are already available. I will just enumerate some possible 
topics without any comments:


Topics for a newsletter article

- Development of convolve-matrix filters in RevTalk
 (From Chipp Walters to Mark Waddingham; 3x3 and 5x5 filters; hybrid 
filters 5x5 to 11x11; main categories and examples of convolve filters)


- Scripting basic photo tools in RevTalk
 (Saturation, hues, gamma correction, sharpen, blur, dynamic range, 
negative image, grayscale, contrast, reducing colors, substituting 
colors etc.)


- The power of despeckle filters

- Reverse engineering Gimp filters (non-Lua filters): Dilute, erode. 
ripple, outline, photocopy, cartoon, pick etc.


- Mirrors and refractions -

- Different approaches to create "seamless tiles"

- Making use of color spaces (other than RGB):HSV, HSL XYZ, YUV, YIQ

- Image gradients and overlays

- Area- vs.single-pixel-oriented filters

- How to create kaleidoscope patterns

- Image borders and frames

- Noise and distortion

- The great potential of using masks in Revolution

- Combining images and selections of images

- The world of "outline" filters - convolve and other filters.

- The role of paintcompression in image processing

- Creating image art with fields, buttons, and char color.




Kind regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: The power of despeckle-median filters: Image examples

[Wilhelm Sanke]

he meantime I have developed a suite of newer image-processing 
stacks which do not have such restrictions, but can be used with images 
of any size.
However, we face a number of problems here, namely the speed problem 
with larger images - as manipulating imagedata in Revolution is really 
comparatively slow. What we need for faster image processing in 
Revolution would be a new conception maybe along the lines of the Lua 
language, which is for example used as an add-on of the GIMP application 
and in many other image-processing tools. See the text of my  post to 
this list "Language comparisons: "Lua" - simpler and faster than 
RevTalk" of March 3, 2010.--


Another restriction of my "Imagedata Toolkit" stack has to be mentioned 
here as a warning to potential users. This stack had been singled out as 
a paradigm for bad layout and color use by a speaker during one of the 
last Rev Developer conferences (I think it was in Las Vegas). Although I 
cannot fully comply with his argumentation there was some truth in his 
deliberations, as with this "preview" stack I had concentrated more on 
contents and functionality than on surface design. Happily this speaker 
did not argue about the contents and later even asked me if he could use 
one of my filters in his own applications.


Kind regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Why...?!

[Wilhelm Sanke]

On Thu Aug 26, 2010, Mark Schonewille m.schonewille at 
economy-x-talk.com wrote:



Hi,

What is the reason again, for triggering the mouseMove message 
whenever a grouped button is clicked? Twice?!


Create stack, create button, group button, set script of group to 
following script:


on mouseMove
  beep
end mouseMove

Each click generates two beeps, one on mouseDown, one on mouseUp. Why?

--
Best regards,

Mark Schonewille


Hi Mark,

I wouldn't bother too much about this. I suppose this is simply another 
of the great number of group bugs that are presently outside the scope 
of interest for the Revolution team.


IMHO I think - given the many group bugs that prevent or impede 
development seriously (at least in my case) - what we need is a complete 
overhaul of the group object and its many irritating features.


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

The power of despeckle-median filters: Image examples

[Wilhelm Sanke]

For those few on the list that are interested in image processing I have 
put together a web page demonstrating the effects of  "pre-processing" 
images with despeckle-median filters before applying convolve-matrix 
filters:


<http://www.sanke.org/MetaMedia/despeckle filters.htm>

Using two images - "St. Remy: Van Gogh's Grove" and "Steve Jobs, the 
iPhone, and Medwedew"- I compare the application of three 
convolve-matrix filters to the pre-processed and un-preprocessed images.


Seems that such combinations of filters can bring out details not to be 
seen in the original image - see the reflections on the iPhone surface - 
and also character traits of persons otherwise not immediately detectable.


Regards,

Wilhelm Sanke


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: cross platform drawers

[Wilhelm Sanke]

On Mon Aug, 2010, Monte Goulding monte at sweattechnologies.com wrote:



Hi

I'm working on InstallGadget 2 and an InstallGadget plugin for rev. 
The plugin is well suited to using drawers on OS X to integrate IG 
settings with the standalone builder interface. I'm just wondering 
what people think I should do on Windows? Has anyone done drawer 
emulation and is it worthwhile and appreciated my users?


Check out InstallGadget 2 & the plugin on Facebook and you will see 
what I mean about the drawers ;-)


Cheers
Monte



I do not know if you could use an old stack of mine for your Install 
Gadget, but it is indeed a drawer emulation for all platforms:


<http://www.sanke.org/Software/Drawers.zip>


The stack demonstrates the use of "drawers" without using the new 
"drawer" command introduced in Revolution 2.1.2. Therefore these forms 
of drawers can be implemented also with older versions of Metacard and 
Revolution and on any platform. Drawers can slide out and back at any 
point of the rectangle of the main stack and even in diagonal directions.


From the "information" pane of the stack itself:

"Using and modifying the scripts of the "drawer"-buttons you can create 
any number of drawer stacks that can slide out in any direction.


1. Set the starting point of the drawer to any point of the sides of the 
drawerbase.


2. Define the direction of the drawer movement in the repeat loop

3. Modify the respective close buttons

Drawers can be created for any platform and with Rev or Metacard 
versions lower than 2.1 or 2.5 as these examples do *not* use the new 
"drawer" command available at present - August 2003 - only in version 
2.1 of Revolution (2.5.1B3 of Metacard) and only for MacOS X."


Best regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Making clickable text links in Rev

[Wilhelm Sanke]

On Sun Aug 8, 2010, tech1 at troutfoot.com tech1 at troutfoot.com wrote:



Hi folks,
I can’t find this in the docs.

Let’s say there’s a scrolling field with a few thousand words.

Is there a way to make some words into clickable links, as in html web
pages, without using their position?

Because the text will be lengthy, and changed at various times, I want to
avoid things like “...set the linkText of word 35429...“

Thanks,
Sandy



My tutorial and sample stack "Hypertextannotations" could be of help here:

<http://www.sanke.org/Software/HypertextAnnotations.zip>

The stack shows three ways to create such hyperlinks. I use a "glossar" 
in which the "words" (can be more than just one word for one link) and 
the corresponding "annotations" (the text that is displayed in an 
automatically resized field near the link when you click at the link) 
can be edited.


Then you activate all the words of the glossar as links anywhere in a 
text without using their position. When you edit the text that contains 
the links (adding text anywhere or cutting parts of the text) all links 
will be maintained. If there are link words in the added text, just 
activate the glossar one more time.


Regards,

Wilhelm Sanke

<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

On Sat Aug 7, 2010, Richard Gaskin ambassador at fourthworld.com wrote:


For the main dictionary entry, use the Documentation specifier when
filing the request in the RQCC.

> If the boundingrect of a group is such a powerful property I wonder why
> the default for groups isn't "boundingrect not empty" and is
> automatically set to the coordinates when a group is created or 
resized ?


It depends what you want to do with the group..  Altering that 
behavior with the boundingRect is useful for making
canvas-like regions, but if you're not after a canvas you may prefer 
the default behavior.



Richard,

I think *you* are the most competent person to re-write the 
"boundingrect" entry of the Dictionary and to specify the details more 
accurately and understandably, after all, as you mentioned, it was you 
who requested such a feature from Scott Raney. And this was probably one 
of the last additions Scott Raney made to the MetaTalk language, as the 
"boundingrect" did not find its way into the Help index of the Metacard 
IDE as we still use it today.


On August 6 you wrote:


But some time ago I needed more canvas-like behaviors,
and Scott Raney accommodated me by adding the boundingRect property for
groups.

Similar to SuperCard's backSize property, the boundingRect lets you
define a rect for the scrollable area of a group regardless of its 
contents.



Question: Can we not achieve the same effect for a fixed scrollable area 
when we simply "set the rect", i.e. not the boundingrect, and the 
locLocation to true? What is the difference for a scrollable area when 
you use "boundingrect" instead?


On August 7 you wrote:


Yeah, the boundingRect property been a godsend on some projects, and I
was quite pleased when Raney added it.  Makes short work of things that
can get quite complicated without it.



Could you possibly provide us - the revolution users - with more details 
and examples, why the boundingrect is a "godsend" and and how it 
simplifies things that otherwise remain complicated?-


Of course, the "boundingrect" is one of the solutions to the "set the 
loc of objects in a group" problem, identical (in that) to the effect of 
the "magic button", and very similar to the effect of Jacqueline's 
proposal to switch off the scrollbars of a group if the image is smaller 
than the group. The only difference when focusing on this bug - as it 
were "on the surface", but not only - is that with the "boundingsrect"  
scrollbars are tolerated with smaller images whereas with Jacqueline's 
proposal you have to turn the scrollbars off.


If would be surely very nice of you and helpful for Revolution users if 
you would tell us more about the other features coming with the 
"boundingrect" property that provide canvas-like behaviors and simplify 
otherwise complicated things.


Thanks very much in advance.

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

On Sat Aug 7, 2010, Richard Gaskin ambassador at fourthworld.com wrote



Wilhelm Sanke wrote:

> Richard,
>
> Thanks for this really valuable information.
>
> "set the boundingrect of group x to the rect of group x" solves the
> complete list of problems, the "setting" and "keeping" bugs are no
> longer interfering and all side effects have gone away - like with the
> magic button, but with even less effort.

Yeah, the boundingRect property been a godsend on some projects, and I
was quite pleased when Raney added it.  Makes short work of things that
can get quite complicated without it.

As much as I enjoy using Rev, there are a few things I miss from when
when I was using SuperCard daily; this was one of them.

> They must be a great amount of similarities between what the
> boundingrect and the magic button achieve,  and if the Rev engineers
> will still try to fix the "set the loc" bug they should also look how
> the boundingrect is coded in the engine.

I think I missed that bug - what's the RQCC#



The first post of this thread of August 3 was intended to be a first 
draft of the report. I did not yet submit the report as I wanted to see 
and possibly include relevant feedback from the list, which seems to be 
justified now.



> The Revolution docs/dictionary should be updated to reflect the
> dependency of "set the loc" in groups on the "boundingrect" property.

Good idea - I've just added this note to the Dictionary entry for the
location property:

 If you encounter difficulties setting the loc of objects
 within a group, see the boundingRect group property in
 this dictionary.

--
  Richard Gaskin



I took a look at the comments in the Dictionary: Here are the comments:

Use the boundingRect property to control how a group responds when you 
move one of the group's controls to the edge of the group.


Value:
The boundingRect of a group consists of four integers separated by commas.

By default, the boundingRect property of a group is set to empty.

Comments:
If a group's boundingRect is empty and its lockLocation is false, when 
you drag an object toward the boundary of the group, the group 
automatically expands, resizing itself to fit. If the lockLocation is 
true, the object is clipped to the group's rectangle.


If a group's boundingRect is not empty and its lockLocation is false, 
when you drag an object toward the boundary of the group, the group 
does not automatically resize to fit its objects. Instead, the object 
is clipped at the boundingRect. (In group-editing mode, the entire 
control is shown, but when you exit group-editing mode, controls 
outside the boundingRect are clipped.)


If the group is a scrolling group, dragging an object in it 
automatically scrolls the group. When you drag beyond the scrollable 
area, the object is clipped.


Some remarks to these comments:

I doubt that a user could see any indication of  the problem of setting 
and keeping the loc in groups in these comments.


Setting the loc of an object is not mentioned.

There seems to be no difference between "boundingrect empty and 
locLocation true" and "boundingrect not empty and lockLocation false", 
the option of "boundingrect not empty and lockLocaction true", which 
would describe the properties of the group as I use it now, is absent in 
the comments.


I could *not* verify the last sentence of the comments: "If the group is 
a scrolling group, dragging an object in it automatically scrolls the 
group".


I think this entry for "boundingrect" in the docs needs to be updated, 
too. And I also recommend to change the note for entry "location" to


"If you want to set the loc of an object inside a group reliably, set 
the boundingrect of the group to the rect of the group".-


If the boundingrect of a group is such a powerful property I wonder why 
the default for groups isn't "boundingrect not empty" and is 
automatically set to the coordinates when a group is created or resized ?


I will test which of the other bugs in my substantial collection of 
group bugs is positively affected by using the "boundingrect" property.


Regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

On Fri Aug 6, 2010, Richard Gaskin ambassador at fourthworld.com


Wilhelm Sanke wrote:

> Actually, there are at least two bugs: The problem of "setting" the loc
> and that of "keeping" the loc - although the lockloc of the image is set
> to true. "Lockloc" in the context of the definition above is also 
broken.

> After having succesfully centered the image, it will - as reported -
> revert to a topleft position in the group

Yes, with the default dynamic behavior of groups this is what most folks
will experience.  But some time ago I needed more canvas-like behaviors,
and Scott Raney accommodated me by adding the boundingRect property for
groups.

Similar to SuperCard's backSize property, the boundingRect lets you
define a rect for the scrollable area of a group regardless of its 
contents.


--
  Richard Gaskin



Richard,

Thanks for this really valuable information.

"set the boundingrect of group x to the rect of group x" solves the 
complete list of problems, the "setting" and "keeping" bugs are no 
longer interfering and all side effects have gone away - like with the 
magic button, but with even less effort.


They must be a great amount of similarities between what the 
boundingrect and the magic button achieve,  and if the Rev engineers 
will still try to fix the "set the loc" bug they should also look how 
the boundingrect is coded in the engine.


The Revolution docs/dictionary should be updated to reflect the 
dependency of "set the loc" in groups on the "boundingrect" property.


Regards and many thanks,

Wilhelm

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

".


With "set the loc" after the first step - using the command once - only 
that portion of the image will be displayed that is identical to the 
overlapping parts of the image set to the topleft corner of the group 
and the area the image would have occupied when it would have been 
really centered. Only after applying "set the loc" another time the 
image will be fully displayed in the topleft corner.
This effect is independent of the place where you might have dragged the 
image to before you used "set the loc".


This special overlapping effect with the "set" command points to fact 
that somehow the area - which would have been occupied by a centered 
image - is treated differently and that "set the loc of img x to the loc 
of img y" apperently produced some kind of result for this area, 
although not the intended one.


With "set the imagedata" the portion of the image being displayed after 
the first step is defined by the overlapping parts of the image at a 
topleft position and the current position of the image before the first 
"set the imagedata" command was applied. This also means that after the 
first step the image might be totally invisible if you had dragged the 
image to a position where no overlapping occurs.


If you click in the area of the image at its topleft position after the 
first step you can revive the missing parts of the image. When you add 
"lock screen" before the "set loc" or "set imagedata" line the image 
will at once be displayed in the topleft corner - without a second step.--


It might be worth exploring whether these image-related peculiarities 
are somehow and distantly connected to other Revolution-specific image 
properties as, for example,  what I have called "pre-PNGs" in my stack 
"More about Masks" and in several posts to this list. An image in a 
stack created by a snapshot (and remaining in the stack or copied and 
pasted into another stack) behaves differently in some aspects from an 
image already saved externally or imported into the stack.-


During the last two years much of my time devoted to programming with 
Revolution was spent in the field of image processing of various kinds. 
I suppose - with a rough estimate - that I spent 20 to 30 percent of 
this time to detect the causes of crashes and to find workarounds for 
less fatal bugs, time I could have really used more creatively - 
although of course bug-hunting in itself can be challenging and interesting.


If you consider this lost time and add the fact that bug reports could 
remain with absolutely no feedback for almost a year, then you might 
understand that anger and frustration can come up. Hopefully, according 
to the new policy announced by Kevin, this will now change.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

On Tue Aug 3, 2010, J. Landman Gay jacque at hyperactivesw.com wrote:


I downloaded your stack and took a look. The problem isn't an unlocked
group (your group was locked.) 


Jacqueline, really thanks for taking a look. Thanks to the others who 
gave feedback, too, but I think by responding to Jacqueline's questions 
I can cover most of the issues.


I did *not* say that the problem is connected to an unlocked group. In 
fact, I stated somewhere in the report, that both the 
image-to-be-centered and the group have their lockloc set to true. I 
should have mentioned this at the beginning.


The scenario I came across this bug - or rather a whole can of bugs - is 
like this:


In an image-processing stack I put the image to be processed inside a 
group. The idea is to be able to display images of any size, images that 
are larger than the fixed rect (800x600) of the group can be scrolled by 
the horizontal and vertical scrollbars or inspected with "mousedown and 
dragging the image" directly. Besides that there is an option to display 
the image as a whole adjusted to a separate window covering the full screen.


So in this scenario the scrollbars are necessary.

Of course there are other possibilities for an image-processing stack to 
display the processed image without using a group, as we have done in 
another joint project, where a "copy" of the image is shown in a display 
image of fixed size: The "real" image is hidden, but at the same time 
transferred to the display image. When the hidden image is changed 
through filters or otherwise this change will then immediately be 
reflected via the text-of-image property in the visible image.



It seems to be the scrollbars around the
group. If I turn them off, it all works as expected.


Unfortunately not quite!


The work-around would be to turn off scollbars, set the loc of the
image, and then turn them on again. It should happen pretty fast, but
you could lock the screen in case.



When you turn the scrollbars on again, the image will immediately snap 
to a topleft position again - like it does in some other cases I 
mentioned (going to another card and back, changing the imagedata etc.)



So something about a group with scrollbars is causing the problem but I
can't tell what. 



Neither can I, but I think there is more involved than just the scrollbars.-

Another test I just did: When you turn the scrollbars off and use one of 
the three scripts of the "automated demonstrations" the stack at once 
crashes/freezes after having set the image to the center.



By the way, the image doesn't always pop to the top
left of the group. If you drag it past the bottom right corner, for
example, it will go almost to the center (but not quite.) 



That is not correct. As it were, you are the victim of an optical 
delusion here, you see only a part of the image! I had described that in 
my report as the "two-steps" effect:


The full image will be visible at the topleft position, if you "set the 
loc of img x to the loc of  group y" a second time  or click at the area 
of the image.


Moreover, like with test button "duplicate colors - lock screen", the 
image full image will be displayed at once at the topleft position when 
you add the line


"lock screen" before line
"set the loc of image "x" to the loc of group "y"".

I'm not sure why the extra button makes a difference, unless it simply
jolts the engine into realizing where the topleft corner of the group is.



That seems to be indeed part of the magic of Harry Potter's button, like 
also the interesting split-button effects.
It will be the task and the pleasure of the Revolution engineers to find 
out what is going on. And they should also contemplate, why the 
alternate possibility to center the image using  "move to the loc of 
group x" works in all cases (with or without scrollbars), but not "set 
the loc to the loc of group x"



It would be good to update the bug report so the team knows what exactly
to look at.
If  I knew myself what is going on behind the scenes, I could of course 
have told them, but I don't.


As the report was already rather long, I have left out some other 
peculiarities.
For instance, setting the loc of the image *not* to the loc of the 
group, but to other x,y coordinates will also produce unexpected results 
especially if x,y are near or beyond the borders of the group.
Also, when saving the stack, it can happen that the part of the image 
which was under the window of the save dialog will be moved horizontally 
for a number of  pixels. I have not yet found out the exact conditions, 
so I cannot reliably replicate this, but it happens from time to time --



Best  regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Harry Potter's magic button: link to sample stack

[Wilhelm Sanke]

I see that the link provided for the sample stack lacked an underscore. This 
should work:

<http://www.sanke.org/Software/Magic_Button.zip>

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Harry Potter's magic button - a solution to another tricky group bug

[Wilhelm Sanke]

==

A few more particulars and peculiarities for those interested in getting 
a broader picture:


If the magic button is absent or hidden and you have managed to center 
the image (either by using the "move" command or by dragging the image 
manually), there are now several additional conditions under which the 
smaller image within the group again snaps to a topleft position - 
although the lockloc of the image and that of the group are set to true.


- when you go to another card and then navigate back
- when you change the imagedata and set the image to the new imagedata
- when you import a new image
- when you close the stack (even after having saved it again) and then 
reopen it.


Another peculiarity is that this snapping to the topleft may happen in 
*two" steps - especially when you change the imagedata with button 
"duplicate colors":


 - at first only the overlapping parts between the image area at the 
original position and the area of the image at the topleft position are 
displayed
 - then when you again change the imagedata - or click on the image - 
the full image is shown at the topleft position of the group.


The easiest way to demonstrate this is to drag the smaller-than-group 
image with mousedown nearer to the bottomright of the group and then 
apply the "duplicate colors" filter twice.


If an image so small  that there are no overlapping parts of the image 
at the start position and its position at the topleft corner, then the 
image will vanish completely. It is "virtually" there and you can revive 
it by clicking near the topleft corner of the group.


When you use the alternate filter "duplicate colors + lock screen" the 
image is set to the topleft of the group in only one step - and remains 
fully visible..


By the way, when you apply filter "duplicate colors" 9 times then the 
original colors of the image will be restored, but this is the normal 
process when using this filter - without any magic.--


I will file a bug report soon and also add the sample stack.

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Quality Control Center - handling of bug reports

[Wilhelm Sanke]

On Wed Jul 28, 2010, Kevin Miller kevin at runrev.com wrote:


On 28/07/2010 10:22, "Wilhelm Sanke"  wrote:

>   As an active supporter and user of Revolution since its beginnings I
> am of course aware of the difficulties and the multitude of tasks the
> Rev team has to address with limited personal resources. But I think
> there is an urgent need to re-organize  the handling of bug reports and
> the management of the so-called "Quality Control Center". To completely
> disregard valuable feedback from motivated users is not the way to keep
> up or build trust for Revolution and its developers.

I agree. I have responded in more detail on this topic and on a number of
other important points relating to the direction of the Rev platform 
on our

revEnterprise improve-rev membership mailing list.

Kind regards,

Kevin



Kevin,

Thank you very much for responding and agreeing.

With your answer you made me look through your recent posts on the 
improve list to find a match for the subject of my own post.


As the members of the use list are also entitled and interested to file 
bug reports and use the Quality Control Center, I assume it is allowed 
to quote from the enterprise list in this case.


The closest match I could find is a passage in one of your posts about 
"New roadmap (Pricing)":



Things are going to get simpler
and we'll be able to use the new options to support the various things our
professional developers want, like more communication, faster progress on
features, a very different approach to bug management and closer
co-operation with the community.
(snip)
All in all, a fresher, stronger, more nimble, more open
company is in process of being born.



Although these are very general statements, some of which I seem to have 
heard before, I appreciate very much that you intend "a closer 
co-operation with the community".  And I hope the "different approach to 
bug management" will be implemented in a way that takes into account the 
existing "unfixed" and "unconfirmed" bug reports, these maybe even with 
a certain priority and an indication of the timeframe for fixing them.


Best regards,

Wilhelm
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Quality Control Center - handling of bug reports

[Wilhelm Sanke]

CCs of this post are sent to supp...@runrev.com and ke...@runrev.com.

There are about 10 or more (minor to critical) bugs associated with the 
group object, which have cost me plenty of time and a huge amount of 
frustation to get to the details of these bugs and eventually to find 
out workarounds if possible. These bugs seem to be totally outside the 
scope and interest of the RunRev team.
My bug report  8275 of Sept. 16, 2009, "Groups: Bugs and features ("last 
group" broken)?", which listed 5 of these group bugs, is stiil shown as 
"unconfirned" as of today - nearly 11 months later!


If they should indeed have looked at the report and cannot replicate the 
bugs, I would at least expect an organized attempt to communicate with 
the bug reporter, maybe asking him for more information or a sample 
stack etc.etc..
 As an active supporter and user of Revolution since its beginnings I 
am of course aware of the difficulties and the multitude of tasks the 
Rev team has to address with limited personal resources. But I think 
there is an urgent need to re-organize  the handling of bug reports and 
the management of the so-called "Quality Control Center". To completely 
disregard valuable feedback from motivated users is not the way to keep 
up or build trust for Revolution and its developers.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Inserting an image into a pre-existing background group?

[Wilhelm Sanke]

Richmond,

Two additions to what Jaque has already pointed out:

To "remove" an image within a group - but at the same time preserving 
the image as an object (that can stiil be used after that) - script - or 
type in the message box "put empty into image "x"". This works for an 
image inside or outside any group.


If you want to replace an image and you want to preserve the former 
image *size*, set the lockloc of the image to true before you import the 
image file the way Jaque has described


 "answer file "choose an image file:"
set the lockloc of img "x" to true
  put url ("binfile:" & it) into img "x""

Kind regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Inserting an image into a pre-existing background group?

[Wilhelm Sanke]

On Thu Jul 22, 2010, Richmond richmondmathewson at gmail.com wrote:



  I have a background group that spreads itself
over something like 50 cards; however, I am
beginning to have serious reservations about
the aesthetics of some of the images I use as
faux-buttons and should like to replace them.

My problem is two-fold:

1. Insert an image into a pre-existing
 background group so it shows up\
 across the 50 pages.

2. Remove an image in a similar situation.

sincerely, Richmond.



Richmond, where is the problem - or what do I miss?

If there is an image object inside your group you can put any image into 
that group (with its backgroundbehavior set to true) - or remove it by 
setting that image to empty.


Best,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Old flagship found (was: Language learning stacks)

[Wilhelm Sanke]

-


I had looked into 2 to 3 versions of Stephen's tools. They tried to 
facilitate creating courseware by offering a more or less pre-designed 
environment where you could choose between different formats of 
teaching/testing - among them various forms of quizzes and also 
multiple-choice - the main task of the user of the tools was to organise 
content and put it into the environment.


I personally had the difficulty that the Windows version of Preceptor 
Tools would not run properly on Windows - to which Stephen provided the 
information that he had not (yet) had the opportunity to test his 
program on Windows.


As Stephen has declared his Tools to be freeware and in case some of you 
may be interested to have a look at these tools, here are two download 
links for a Windows and MacOS version from my website.


<http://www.sanke.org/Software/ptools_v1.0.5.sit>
<http://www.sanke.org/Software/ptools_1.0.6.zip>

Mark, as I could not find recent download links for the "freeware" 
version, these are 30-days trial versions.


Kevin will probably know where to find the freeware-download link. Maybe 
he can help here?


Regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Pink Elephants & MC Tutorial

[Wilhelm Sanke]

On Sun Jul 11, 2010, David C. davidocoker at gmail.com wrote:



Thank you, Wilhelm!
It seem to run just fine, but many of the graphics (including the
elepahant ) must have been stored as files instead of embedded into
the stack because they never appear on screen. Still though, it's fun
to see the demo again. :)

Heh, I never knew that Kevin was the author... that's really cool!
(Thanks Kevin!)

Best regards,
David C.


Hello David,

what was missing was a folder "demo" that contains all the graphics and 
one video. I have now bundled this folder and the mcdemo2 stack and 
uploaded it to


<http://www.sanke.org/Software/MC-Demo.zip>.

Best thing to do, put the stack and folder into the same folder where 
the Rev or Mc engine is located. Works even with Rev 4.5-dp3, but you 
will see the whole design has sort of a "historical" quality. This 
surely does not detract from the overall inventive and attractive format.


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Pink Elephants & MC Tutorial

[Wilhelm Sanke]

On Sun Jul 11, 2010, David C. davidocoker at gmail.com wrote:



Hey folks,
I'm wondering if there might be a copy of the old MetaCard demo stack
available for download anywhere?
I was playing around this morning, ended up at the old MetaCard site
and started thinking about pink elephants for some silly reason... ;-)


Best regards,
David C.



You can get it from here:

<http://www.sanke.org/Software/mcdemo2.mc>

The stack runs both under the Metacard and Rev IDE. Its author was a 
creative chap named Kevin Miller, at that time a young cooperator with 
Scott Raney, the inventor of Metacard.


Maybe we should persuade Kevin to develop a new version for Revolution 
introducing us to most of the features of Revolution in an entertaining way.


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Language learning stacks (an addition)

[Wilhelm Sanke]

A couple of years ago someone from this list had presented a 
language-learning stack with various exercise formats. Unfortunately I 
forget the author and the name of the stack. It must be hidden somewhere 
on my harddisks, presumably on my old G3 Mac. I think the stack had been 
available under "Third party contributions" from one of the RunRev sites 
(the FTP one?).


Kevin (our CEO) had been enthusiastic about the stack and called it to 
be something like "the coming flagship of Runtime Revolution". This also 
points to the fact that at least at that time the Rev team had a genuine 
interest in educational software.


As a new product, the structure and features of the stack needed of 
course to be discussed, e.g. in the multiple-choice section you would 
find only fixed-position distractors - a fault you usually would learn 
to avoid in the first session of a workshop on educational programming.


Otherwise the stack - as far as I remember - in my opinion had a real 
potential to be enhanced further.


Maybe Kevin could dig out the stack from the RunRev archives and offer 
it to a group or an individual from this list as a basis for further 
development?


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Language learning stacks

[Wilhelm Sanke]

On Sat Jul 10, 2010, Mark Swindell mdswindell at cruzio.com wrote:

Has anyone developed any vocabulary/ language learning stacks in Rev?  
Seems like an apt application for the tool, but I didn't see anything 
in revOnLine.  Picture dictionary type things with rollovers for 
different languages?  Remember those First Thousand Words books with 
contextualized drawings showing vocabulary for the kitchen, barnyard, 
garden, etc.?



We had been discussing such things on this list - and the 
"education-revolution" list 
<http://mail.runrev.com/pipermail/education-revolution/> (last entry Feb 
2007) - when Marielle Lange was still with us.


At our institutution we are using a set of language exercises "Language 
Suite" developed with Metacard/Revolution. The format of the exercises 
is more "traditional" , having a distant similarity to the language 
programs of Wida Software <http://www.wida.co.uk/noframes/index.htm>.


Our "Language Suite" has until now not been released publicly. Maybe we 
should present some examples in the near future.


An overview of the "Language Suite" - although only in German - can be 
found here

<http://www.sanke.org/MetaMedia/LanguageSuite.htm>.

Among the exercises are such based on the "cloze" principle with 
"fill-in" and "drag.and-drop" variants, other types of "text 
reconstruction" (scrambled paragraphs, lines, words - along with the old 
"Sequitur" format (originally developed on the C 64) where a text is 
complemented by adding the next line being chosen from 4 multiple-choice 
lines), and a number of word-based exercises (words and definitions in 
the same language, bi-lingual word exercises, multiple-choice and memory 
formats).--


A number of language-learning related stacks - not belonging to the 
"Language Suite" - can be found and downloaded from my website 
<http://www.sanke.org/MetaMedia>, but I am not sure whether these stacks 
run flawlessly with the newer versions of Rev.
There are meant as "sample stacks" for students who engage in 
educational programming. Other stacks were reactions to specific 
discussions on this list.


Examples.

- <http://www.sanke.org/Software/Animals-drag.zip>

Drag-and-drop exercise with animal pictures and translations of the 
corresponding names.


- <http://www.sanke.org/Software/ImageAndWords.zip>

Learning words through pictures in five different versions: Wordshow, 
Move and Click, Test and Learn, Test with Loop, Final Test. Basic part 
of the stack is an image with polygon overlays corresponding to the 
outlines of objects. Mode "Test with Loop" is an example for an 
instructional programs that allows the repetition of unsolved problems.


- <http://www.sanke.org/Software/MultipleChoice.zip>

This stacks contains 7 different formats of multiple-choice questions, 
arranged in "incremental" steps from a primitive version with fixed 
positions of solution and distractors (which should be avoided by all 
means) to a version with flexible positioning with the option to choose 
the number of problems from a repertoire and a "loop" for unsolved 
problems. After all problems have been worked on, the user gets the 
option to try the "wrong" problems once more etc. Thus the programs 
adapts to the individual needs of the user.


- <http://www.sanke.org/Software/SimpleWordScramble.zip>

A simple "word-scramble" exercise with various forms of learner support 
and the possibility to edit the "lexicon".



- <http://www.sanke.org/Software/HypertextAnnotations.zip>

Two versions of "annotations" using "linkclicked" or "clicktext". 
Clicking on words set to "bold" or "link" will display an "annotation" 
field near the word containing additional information (translation, 
definition etc.). The annotated words are defined in a glossary field.


- <http://www.sanke.org/Software/Wordmatch.zip>

The main purpose of this stack is to demonstrate how the findings of  
the discussion in thread "Dynamic labels for buttons with (oddshaped) 
icon images?" on the use-revolution list in Feb 2009 could be applied to 
a practical example. From the two "help" buttons:


"Drag a green button with mousedown to one of the yellow frames.

If the label of the red button to the right of the frame is  the correct 
translation, the dragged button will move into the frame on mouseup.

If it is incorrect, then the dragged button will return to its former place.

Button "vocabulary"  randomly selects six pairs of matching words from 
the hidden field "Lexicon".


Button "repeat" distributes the currently selected matching words 
differently to allow further training with the same words, thus 
eliminatin

Thoughts and facts about "text of image", "imagedata", and "paintcompression"

[Wilhelm Sanke]

red in a custom 
property and resetting an image to these data: With paintcompression set 
to PNG this can be up to 12 (twelve) times slower than with RLE.


If you embed C- or Lua-externals for imagedata processing they are of 
course surprisingly faster, but the basic relative speed difference 
caused by paintcompression remains, as the imagedata manipulated by the 
external must after that be reset in the Revscript part.--


Generally, imagedata processing in Revolution compared to most image 
tools is rather slow, as it was not developed with a focus on image 
processing.


Maybe in the medium future improvements for image processing in 
Revolution could be achieved, given the present urgent need to work on 
other areas (including fixing bugs) on the backgound of the budget and 
personal resources of the Rev team.


A lot could be achieved by adding externals for image processing to Rev. 
I had given this angle a thought in my post of March 9, 2010, to this list


"Language comparisons: "Lua" - simpler and faster than RevTalk?" .

.
Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)

[Wilhelm Sanke]

On Fri Jun 25, 2010, Ben Rubinstein benr_mc at cogapp.com wrote:



On 25/06/2010 17:36, Wilhelm Sanke wrote:

>  And, if someone finds out that "you can crash Rev with
> only four lines of script" this should definitely arouse the attention
> of the responsible members of the Rev team, irrespective whether the bug
> report is multi-faceted or concentrated on one single sub-point. The Rev
> team should be competent enough to deal with a number of related
> troubles at the same time, or deal with them step by step. I believe
> that they are basically capable to handle also complicated issues, they
> are not first-graders in computer science.

But they are busy people, who have to choose where to put their time.



So are we!. My time is equally valuable. I think the relationship 
between the Rev team and their customers, supporters, cooperators etc. 
is one of mutual acknowledgement and respect without any trace of a 
hierarchy.


I believe the unresponsiveness of the people from Rev in this case - an 
unresponsiveness which happily does not happen all the time, I indeed 
did have quite a number of normal and positive experiences - is mainly 
an organisational problem.
If you set up a bug database for Rev users, you have also to develop 
regular procedures to communicate with the sender of a bug report in a 
narrow time frame.  If there are open questions concerning a report - 
facts and arguments that may be totally clear in the mind of the sender, 
but actually need extra clarifications and additional information for 
the member of the Rev team that is assigned to the bug - then there is 
the need (and there should be the time) to contact the sender about it.
Just staying mute for 9 months, doing nothing, is not appropriate and 
helpful - and certainly counterproductive to the goals of further 
development and improvement of Revolution and establishing a good 
working relationship with its users.



  I took
some time to work through the bug, which is actually called "Groups: 
Bugs and
features ("last group" broken)?".  It refers to a way of crashing Rev, 
but
doesn't give enough information.  I tried, yesterday, to reproduce the 
bug
using the script fragment in the bug report, but without success.  
However,
that may be because I didn't know the definition of 'pre-PNG'. Perhaps 
I would
have discovered that by following the clue of "my recent post to this 
list",
but that was more time than I had.  I tried with a PNG, and it didn't 
crash.



As I had stated in the bug report, the crash occurs with what I have 
called and defined as "Pre-PNGs", PNG images created inside Revolution, 
but apparently differing from PNGs created with other image tools. This 
in itself may be a bug.


I will quote here from the relevant links for the definition of Pre-PNGs 
which I had supplied in my bug report (My post to the use-revolution 
list "How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines" 
of  August 26, 2009, and the introduction to stack "More about Masks"

<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>):

"Pre-PNG" images are basically those that are created or modified (as 
to their imagedata) in Revolution and have not yet been saved as 
external files and then been re-imported. Even if you export a 
snapshot using "to image x as PNG" (image x being an image already 
existing on the card), the resulting image will remain a Pre-PNG, also 
copying and pasting the Pre-PNG to another card or stack preserves the 
quality of the Pre-PNGs which behave differently in some respects. For 
details see my comments in "More about Masks".


From the introduction to stack "More about Masks":

A final observation concerning the creation of masks inside Revolution 
and using the "import snapshot" format:


If the resulting mask image is not first saved as an external file and 
then imported again, meaning if it remains as freshly created inside a 
stack or was just copied from another mask-producing stack, then this 
mask image will have a different quality, which we might call a "pre-PNG".


Pre-PNGs behave somewhat differently than normal PNGs: You cannot 
transfer its alphamask to the image-to-be-masked when the pre-PNG is 
hidden, at least not several times with resizing. After you have 
resized a pre-PNG during the masking process, you might find that it 
is suddenly "empty", but it can be restored when you copy and paste it 
(it then appears in its original size and shape).
A workaround to overcome this problem is to store the mask in a custom 
property of its own and then to "initialize" the mask each time before 
it is used in the calling script:


"put the CPimg of img "transition" into img "transition""

But of course you can easily convert a pre-PNG to a full 

Re: Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)

[Wilhelm Sanke]

On Thu, 24 Jun 2010, Ben Rubinstein  wrote:


On 22/06/2010 16:01, Wilhelm Sanke wrote:

> > Apparently he had taken a look at the Revolution bug database with its
> > enormous lags in fixing even fatal bugs,  e.g. Report #8275 "Groups:
> > Bugs and features ("last group" broken)?" of  Sept 16, 2009, which
> > astonishingly is still listed as "unconfirmed" although it contains a
> > recipe to crash Revolution with only 4 lines of script.

Wilhelm,

I share your frustration with bug reports remaining uncomfirmed for long
periods, although I also agree with others (and perhaps you) that an
absolutist approach of no-new-features-until-every-bug-is-fixed is not 
sensible.


However, taking a look at the report you mention, #8275, I can't find the
recipe for crashing Revolution with only 4 lines of script.  There are
references in that report, to another report "How to reliably crash 
Rev 3.5
and 4.0-dp3 with four script lines", but from various searches in 
Bugzilla I

am unable to find it.  Can you give me the report number?

Many thanks,

Ben

PS Thank you for taking the trouble to report issues in Bugzilla as I 
know it
takes effort and it is a service to the community.  But I would 
recommend, to
get the maximum value in return for your trouble, creating separate 
reports
for each issue so that each can be understood as simply as possible, 
rather

than creating one very long report that ties together several issues.


Ben,

Thank you for looking into this matter. You are certainly right when you 
recommend filing separate bug reports.


One thought that led me to put together a more comprehensive report is 
the assumption that at least some of the listed bugs are somehow related 
to each other. And, if someone finds out that "you can crash Rev with 
only four lines of script" this should definitely arouse the attention 
of the responsible members of the Rev team, irrespective whether the bug 
report is multi-faceted or concentrated on one single sub-point. The Rev 
team should be competent enough to deal with a number of related 
troubles at the same time, or deal with them step by step. I believe 
that they are basically capable to handle also complicated issues, they 
are not first-graders in computer science.


There were 5 to 6 more sub-points concerning groups I was going to add 
to that report, but  I had waited for a first response - which never was 
sent.up to now.


The four-liner is contained in point 5 of my bug report - see below - 
and the post I mentioned there


"How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines"

was sent to the use-revolution list on August 26, 2009 - and can be 
found in the archives.




5. Groups belong to the factors in an already reported scenario for safely
crashing Rev

I have described this in detail in my recent post to this list "How to 
reliably
crash Rev 3.5 and 4.0-dp3 with four script lines". Here I just point 
out that
"group" is among the elements causing to crash Rev and refer you to my 
original

post for more details.

The following script assumes that you have set the angle of img "test" 
to an
angle other than 0, that img "test" is ungrouped, and that img "Test" 
belongs

in the category of "Pre-PNGs".

  "lock screen
  select img "Test"
  group
  set the angle of img "Test" to 0"

For the definition of "Pre-PNGs" see my above-mentioned post or the
introduction of my stack

<http://www.sanke.org/Software/MoreAboutMasksRev3.zip> in the text 
brought up

on the menu card from the topright introduction button.



Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [OT] Computer news from Kassel

[Wilhelm Sanke]

I am very much aware of the fact that software is almost never bug-free.

Apart from the first part - where I wanted to direct your attention to 
the computer pioneer Konrad Zuse - the rest of my post was written with 
some degree of  tongue-in-cheek (both in its positive and negative 
denotations), which some of you may have overlooked.


Also, I consider it an ironic coincidence in itself that we have got a 
new colleague with a doctorate from Edinburgh University that 
specializes in software trouble-shooting.-


I have been less complaining that there are bugs in Revolution, the main 
point was my irritation that a bug report can still be listed as 
"unconfirmed" after 9 months. What use is a bug database when it is 
looked at only selectively? And in case described bugs could not be 
replicated then I expect some follow-up communication from the side of 
the Rev team.


For your convinience I re-quote my post below.

Regards,

Wilhelm Sanke

===

1. People around Kassel - and elsewhere - today celebrate the 100th 
birthday of Konrad Zuse, the inventor of the first programmable computer.


Some extracts from Wikipedia:

"Konrad Zuse ( 22 June 1910) was a German engineer and computer pioneer.

His greatest achievem was the world's first functional 
program-controlled Turing-complete computer, the Z3, in 1941 (the 
program was stored on a punched tape).


Zuse also designed the first high-level programming language, 
Plankalkül, first published in 1948."


Zuse developed his computer living in a small town near Kassel. His 
Z3-Computer is one of the exhibits in the "Technikmuseum" of Kassel.



2. The University of Kassel this semester added another position of a 
"Junior Professor" in "Computational Sciences" to the faculty of its 
IT-Department.


The first holder of this position got his doctorate at the University 
of Edinburgh. His special field in research and teaching is "The 
structure of programming - trouble-shooting and avoidance".


It is as yet unknown whether during his stay in Edinburgh the new 
professor had come into contact with Revolution or the Revolution 
team, but considering the topic of his work this seems to be highly 
probable. Apparently he had taken a look at the Revolution bug 
database with its enormous lags in fixing even fatal bugs,  e.g. 
Report #8275 "Groups: Bugs and features ("last group" broken)?" of  
Sept 16, 2009, which astonishingly is still listed as "unconfirmed" 
although it contains a recipe to crash Revolution with only 4 lines of 
script.


Although this report is now almost one year old, apparently nobody 
from Revolution so far has bothered to take a look at this bug report. 
It might be a wise move from the side of the Revolution team to enlist 
the support and cooperation of our new professor.--


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[OT] Computer news from Kassel

[Wilhelm Sanke]

1. People around Kassel - and elsewhere - today celebrate the 100th 
birthday of Konrad Zuse, the inventor of the first programmable computer.


Some extracts from Wikipedia:

"Konrad Zuse ( 22 June 1910) was a German engineer and computer pioneer.

His greatest achievem was the world's first functional 
program-controlled Turing-complete computer, the Z3, in 1941 (the 
program was stored on a punched tape).


Zuse also designed the first high-level programming language, 
Plankalkül, first published in 1948."


Zuse developed his computer living in a small town near Kassel. His 
Z3-Computer is one of the exhibits in the "Technikmuseum" of Kassel.



2. The University of Kassel this semester added another position of a 
"Junior Professor" in "Computational Sciences" to the faculty of its 
IT-Department.


The first holder of this position got his doctorate at the University of 
Edinburgh. His special field in research and teaching is "The structure 
of programming - trouble-shooting and avoidance".


It is as yet unknown whether during his stay in Edinburgh the new 
professor had come into contact with Revolution or the Revolution team, 
but considering the topic of his work this seems to be highly probable. 
Apparently he had taken a look at the Revolution bug database with its 
enormous lags in fixing even fatal bugs,  e.g. Report #8275 "Groups: 
Bugs and features ("last group" broken)?" of  Sept 16, 2009, which 
astonishingly is still listed as "unconfirmed" although it contains a 
recipe to crash Revolution with only 4 lines of script.


Although this report is now almost one year old, apparently nobody from 
Revolution so far has bothered to take a look at this bug report. It 
might be a wise move from the side of the Revolution team to enlist the 
support and cooperation of our new professor.--


Best regards,

Wilhelm Sanke


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Replace rgb1 with rbg2

[Wilhelm Sanke]

On Tue, 11 May 2010, JosepM  wrote:


Hi List,

How can I change one color rgb by other color rgb into a image?
I found some scripts in the list that show some ideas to accomplish it. But
nothing work for me.

I binaryencode("C",red) to replace with other binaryencoded value, but no
result
I replaced using numtochar, but no result

It's posible do the operation inside a rect of some object?

Any idea?

Salut,
Josep



Josep,

your question had also been asked on this list on March 15 by Tiemo Hollmann.

For my convenience I quote here my answer to Tiemo's question along with examples of 
images with "replaced colors" and links to scripting such replacing:


On  March 15, 2010, Tiemo Hollmann TB toolbook at kestner.de wrote:


 I am not that familiar with the image manipulating capabilities of rev. I
 have a batch of images with a person in front of a blue background.

 What I would like to do is to change the blue background against a white
 background, so that a printed image has a better contrast. Up to now I
 thought that this is a photoshop job, but I am always again surprised what
 people do with rev (blending, masking, etc.). Or any externals for Mac and
 Win? I don't know if at all it would be possible, to find and select
 automatically the "background" (e.g. select always the topleft corner) and
 select all of the blue, like photoshops wizard selecting tool with some
 tolerance of 10 or 20%, because the RGB isn't that plain over the whole
 background.


and

stephen barncard stephenREVOLUTION2 at barncard.com answered:


 you mean you want a "magic wand" or "replace color" tool? I don't think rev
 can do that natively. Adobe may even have a patent on it.



I think "to replace a color in an image" is one of the simpler tasks feasable 
with Rev (see farther below for the recipes).

There are some on this list that have explored possibilities of image editing 
with Rev - and from which I have learned much when I started myself to 
experiment with such things. Some of the results and related image-manipulating 
tools can be inspected on my website

<http://www.sanke.org/MetaMedia>.

The two "Imagedata Toolkits" from 2006 and 2007 contain more than hundred 
filters and other tools to manipulate images. A number of newer stacks are still in the 
process of being prepared for public release.

The basic problem with using Rev for image processing is that with big-sized images the processing speed can 
be very, very slow. Another problem are a number of bugs in Rev that led to rather frequent crashes when I 
was working on a set of other tools ("Photo Patchworks", "Gradientology", 
"Kaleidoscope Tool"), which has substantially delayed their release - along with the fact that Rev 
is no longer in the center of my interests as it has been before.

I have addressed the speed and crash problems on various occasions and also in my last post to this 
list of March 9: "Language comparisons: "Lua" - simpler and faster than 
RevTalk?" (which you can also get from here:
<http://www.sanke.org/MetaMedia/LanguageComparisonsLua.rtf>)

and in which I announced two other stacks "Exploring Hues" and "Lua Filters". Both stacks 
contain "replace" tools, one that I ported from Lua and others that I had developed earlier on my 
own.

Concerning Tiemo's question:

I replaced (a range of) colors colors in two images in two different ways:

1. Replacing a color range with a "plain" replace color

2. Replacing a color range while preserving "structures" in the color area 
being replaced, for examples the clouds on the blue sky that now look red like the 
replaced color of the sky, but remain discernible inside the new red background.

Two examples for each approach:

<http://www.sanke.org/MetaMedia/Town-original.jpg>
<http://www.sanke.org/MetaMedia/Town-RedBG-plain.jpg>

and
<http://www.sanke.org/MetaMedia/Landscape-original.jpg>
<http://www.sanke.org/MetaMedia/Landscape-RedBG.jpg>

You find the necessary scripts here:

<http://www.sanke.org/MetaMedia/ReplaceScripts.rtf>

The procedures to replace the colors in this case are like here (many other 
approaches are of course possible).

- select a color-to-be-replaced by clicking on the image and getting the 
"mousecolor" using a script in the image

- define a "range" for that color via an ask dialog

- get the replace color from somewhere; in my case I used a color field whose background 
colors I set with RGB sliders - as in the "Color Chooser" stack.

- finally press the replace button (and repeat that process if necessary to 
refine color selection and range).

I also use a movable graphic on top of the image to restrict such "replace 
color" (or any other) effects to a specific area of the

Re: Object is not an image when Crop command

[Wilhelm Sanke]

JosepM jmyepes at mac.com wrote:


OK. Now is imported into imagedata, but now say that is not a 
rectangle... :(

buf...

It's posible to export or copy a portion of the image but with a irregular
shape? 



and Scott Rossi scott at tactilemedia.com answered:



Recently, Devin Asay wrote:

> Crop only works with a rectangle. There may be others on the list 
who have

> figured out how to use an irregular shape as an image mask.

You can't.  You can only group the graphic and image and use combined ink
effects.  Very limiting.  You can see the Spotlight demo on this page 
as an

example:
<http://www.tactilemedia.com/site_files/software/tutorials.html>




Hello Joseph,

It *is* possible to "export or copy a portion of the image but with a 
irregular

shape".

Check out our stack "More about masks"

<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: New version of RunRev makes .png images all black

[Wilhelm Sanke]

william humphrey bill at bluewatermaritime.com wrote:


Has anyone using new RunRev build 4.5.0 dp 3 noticed that .png images
display all black now? I have to go through and convert every one to 
gif to

get them to display correctly.



What platform are you using?

On WindowsXP PNGs in build 4.5.-dp3 display correctly.

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Microsoft is really annoying

[Wilhelm Sanke]

On Wed Apr 21, 2010; Bob Sneidar bobs at twft.com wrote:



Hi Wilhelm.

(snip). So it does not surprise me that your visiting a reputable site 
resulted in an infection. What DOES surprise me is that your antivirus 
(assuming it is up to date) did not catch it. Perhaps this happened 
before you installed the antivirus?


The hsyfea.exe looks like a random file name, which was typical of a 
particularly nasty bit of malware I came across a while back called 
coolwebsearch. The installer installed several variants of itself 
using random file names, which required a program called HijackThis 
and a series of safe boots to remove the hijacker. Even then, with 
some flavors of the "adware" you never got all the pieces, and the 
recommendation at that point was a clean reinstall.


The other one turned up some interesting google hits. I believe this 
to be a particularly nasty one, but if your Antivirus found it, then 
it should have prevented it, unless as I said, you got it before you 
installed Antivirus. If you got it first, then there is a possibility 
it installed a rootkit, in which case nothing but a wipe and reinstall 
to a new partition, and to be safe, a reset of the CMOS first, will 
guarantee it's removal.


My condolences.

Bob



Hi Bob,

Again, thanks for your feedback and your condolences!

My Antivirus had been in place *before* my computer was infected. The 
software had been installed by an IT-competent colleague, but - as I 
understand now - set to a medium scan level to prevent too much delay on 
startup of the computer. I had changed the scan level to "high" after I 
had experienced the constantly appearing ads and subsequently found the 
two viruses.


Two findings concerning the Internet Explorer on my WindowsXP machine, 
which cannot be removed, but apparently somehow deactivated by 
transferring a number of movable supporting files to another folder:


- IE  can no longer be started even if you click directly on the exe-file.

- There have been no automatic updates of WindowsXP since I have 
deactivated the Internet Explorer, which could mean that IE plays a role 
in the update process.


Best regards,

Wilhelm
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Microsoft is really annoying

[Wilhelm Sanke]

On Apr 16, 2010, at 12:27 PM, Paul D. DeRocco wrote:

> I use Windows day-in, day-out, for software engineering, electronic
> engineering, math, Photoshop editing, mapping, and constant web browsing.
> I've been a heavy Windows user since 3.0, and am currently running XP and
> Win7 on three machines. Although I have a virus scanner, I don't even 
bother

> to run it in the background, only invoking it manually when I download an
> install file from the internet.
>
> Despite all this, I've _never_ had a virus or any kind of malware. My 
only

> system failures have been the occasional result of a RAM or hard disk
> failure. So either I'm doing something terribly right, or you all are 
doing

> something terribly wrong.
>
> --
>
> Ciao,   Paul D. DeRocco
> Paulmailto:pderocco at ix.netcom.com

I repeat here for emphasis:


So either I'm doing something terribly right, or you all are doing
 something terribly wrong.



I tried to recapitulate what I could have done "terribly wrong". First, 
I have got both a virus scanner running in the background and one which 
I invoke manually from time to time.


I was searching for programs that use the Gluas-plugin for embedding the 
Lua language for image processing and - among other sites - arrived at


<http://www.thebest3d.com/gluas/>

which seems to be safe.

From there I clicked the link to "Pixarra TwistedBrush Pro" and that 
seems to me to be the source of all the trouble, meaning simply just 
going to that site. I did not download anything from the TwistedBrush 
site. This happened twice, I will not test this a third time. Maybe 
anybody else could check?


The following malware was then installed on my WindowsXP computer:

Hsyfea.exe (in C:Windows)
sshanas21.dll (in C:windows\system32)

which then seems to have launched the Microsoft Internet Explorer about 
every 5 minutes (until I "disassembled" the Internet Explorer).--


Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Microsoft is really annoying

[Wilhelm Sanke]

On Thu Apr 15, 2010, Bob Sneidar bobs at twft.com wrote:


Hi Wilhelm.

I know pretty much why all of these things you mentioned work the way 
they do but I will not go into that here. What you have is a 
particularly nasty flavor of spyware, that has several processes that 
checks up on the other bits of itself to make sure you don't do 
exactly what you are doing. When they detect that you are attempting 
to remove the other pieces they simply restore them.


There are a couple of approaches I could recommend, but none of them 
are guaranteed to succeed, at least not completely. Once you get a bug 
like this, only a wipe (including deleting the partition and creating 
a new one) and reinstall of the OS is going to guarantee success.


(snip)

2. Install XP sp2 or higher (avoid Vista just because it sucks, Win 7 
is great)



Hello Bob,

Thank you for your comprehensive analysis of my troubles and the 
recommendations of how to proceed.


I am already runnning "XP sp2". - Just to make this clear, would you 
think it possible that the Microsoft "Internet Explorer" itself could be 
transformed into such a self-replicating spyware?


In any case, since I have "disassembled" the Internet Explorer in the 
way I described in my last post, I am - until now - no longer the target 
of such annoying intrusions, or is this merely a coincidence in time?


To test the protectiveness of Microsoft for the IE - as I had pointed 
out which was the cause for the European Union to sue Microsoft - I 
looked at one of my other Windows computers also running WindowsXP SP2 - 
an Asus laptop: I encountered the same problems here when trying to 
remove the Internet Explorer.
Renaming the folder is being denied, renaming file "iexplore.exe" is 
possible, but immediately after the renaming a new instance of 
"iexplore.exe" appears.


Maybe we could get the European Union to sue Apple as well in case they 
do not alter their presumed restrictive policy concerning the 
development of apps for IPhone and iPad? After all, although they have 
not yet introduced the new European currency, Edinburgh and the UK are 
indeed lying on the Northern fringe of Europe.



That about sums it up. If all that seems unreasonable, I would suggest 
looking into the Apple OS X. Nothing is perfect, but real exploits for 
this OS are very rare, and there are none I know about presently that 
a fully patched OS can be compromised by. I am an IT pro and I have to 
live and work in both worlds. Most of my time is spent fixing and 
protecting the Windows side of things.



I also live in both worlds and have used MacOS since the invention of 
Hypercard. But I need Windows, because most of the computers in our 
institution run Windows, with an increasing shift towards Linux. Only 
our College of Fine Arts relies mainly on MacOS.


Best regards,

Wilhelm

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Microsoft is really annoying

[Wilhelm Sanke]

The subject of this thread - which was started by me - sounds somewhat 
harsh and unfair, but the ongoing story of annoying popups of phony 
messages transported by the Microsoft Internet Explorer - without having 
been launched by me in each case - reminds me of the fight between 
Microsoft and the EU - the European Union - about forcing Microsoft to 
deliver a Windows platform that is not necessarily tied to an embedded 
Internet Explorer. At the moment I am not fully clear about the outcome 
of the fight. I remember that Microsoft should pay an amount of several 
million dollars, but I do not know, whether they have paid this sum and 
at the same time have changed their strategy.


At least, from my experience during the last days, they have not yet - 
despite all the ongoing automatic updates - implemented the possibility 
to disengage their Internet Explorer from WindowsXP.


A virus scan found 3 viruses on my computer, interestingly two of them 
with names identical to such of Windows system files.
Removing this trojans did not help. After a while the ads via the 
popping-up Internet Explorer continued.


I then thought about deinstalling the Internet Explorer. Using the 
Windows-provided de-installer I was informed that about 150 listed 
programs were somehow tied to the Internet Explorer and that the removal 
of the IE could produce serious damage. Among the programs listed were 
such like "TwistAWord" (scripted in RevTalk), "Aquasoft DIASHOW mobile", 
"Route 66 Sync", "Lua for Windows", "Mozilla Firefox", "Nokia Ovi System 
Utilities", but of course also quite a number of programs which might 
indeed been somehow connected to the IE. I therefore discontinued this 
approach to remove the IE.


I then tried to move the whole IE folder into the trash can. This is 
however impossible!


Next step: I renamed the IE folder. Likewise impossible.

Then: I tried to rename the file "iexplore.exe". This was possible, but 
after a few moments a new copy of the IE appeared in the folder ( this 
was independent of the fact, whether I was connected to the net or not)


Last resort: I created a new folder (named "Hide") and tried to move the 
whole IE folder into that new one. This succeeded to some extent: Most 
of the files of the IE folder were moved into the new one, only file 
"iexplore.exe" itself along with two other files and an extra 
subdirectory refused to be moved.


At least I have now separated IE from a number of accompanying files, 
and since then - so far - no new information about having won a new 
"Toyota SUV", an iPad, or a journey around the world have appeared via IE.


I hope this state will now remain so, but I am not entirely sure.

Regards,

Wilhelm Sanke


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Microsoft is really annoying!

[Wilhelm Sanke]

Thanks for the various hints!

As browsers on Windows I use "Firefox" and "SeaMonkey", the open-source 
successor of Netscape, the latter on recommendation of our "Information 
Science" department. SeaMonkey, like the older Netscape, preserves the 
unity of web browsing and mail services.


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Microsoft is really annoying!

[Wilhelm Sanke]

I had just written:

Since this morning - after 2 automatic updates on my WindowsXP PC, 
which took place when I shut my computer down after the first session 
- I am constantly being pestered by the Microsoft Internet Explorer 
popping up when I connect to the net. When I close the Explorer with 
the dialog "Internet Explorer is your default web browser? Yes, No" 
(or similar) with the "no" button, it closes, but reappears after a while.


This is a real nuisance!

Anybody else has experienced this, too? 



In the meantime during a half hour this happened 4 times.

Last time the website

http://www.planet49.com/cgi-bin/wingame.pl?partner_pk=607&wingame_pk=74&sub_id=

came up with the Internet Explorer, featuring iMac, iPhone, and iPad, 
and telling me to choose my gift - and to solve a problem before and 
submit my data.


and 5 minutes later while I am writing this:

http://www.freelotto.com/register.asp?skin=Rainbow&noepu=1&partner=1060965&affiliateid=

congratulating me to have won 2,087.56 $.

Happily my - apparently my somewhat obsolete and slow- virus-detecting 
program stepped in at that point and I deleted the trojan. Hope this is 
the end of the story.


Sorry to have bothered  you with this crap.

Regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

OT: Microsoft is really annoying!

[Wilhelm Sanke]

Since this morning - after 2 automatic updates on my WindowsXP PC, which 
took place when I shut my computer down after the first session - I am 
constantly being pestered by the Microsoft Internet Explorer popping up 
when I connect to the net. When I close the Explorer with the dialog 
"Internet Explorer is your default web browser? Yes, No" (or similar) 
with the "no" button, it closes, but reappears after a while.


This is a real nuisance!

Anybody else has experienced this, too?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Cut off from receiving mails for four days

[Wilhelm Sanke]

I was cut off from receiving any emails from March 12 to today - March 
17, 9 AM. Happily I could still send mails and read the revolution archives.


The reason was that the IT-Center of our university installed a new and 
improved email system, but with problems in the beginning. After a 
longer telephone conversation with the IT-center the problem now seems 
to have been fixed. A test mail from the IT-Center finally arrived here 
at 9 AM.


Should anybody from the list have tried to contact me offlist, please 
re-send your posts, as all mails during the cut-off  were lost.


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Replace colors (was: can rev supply image editing features?)

[Wilhelm Sanke]

On  March 15, 2010, Tiemo Hollmann TB toolbook at kestner.de wrote:


I am not that familiar with the image manipulating capabilities of rev. I
have a batch of images with a person in front of a blue background.

What I would like to do is to change the blue background against a white
background, so that a printed image has a better contrast. Up to now I
thought that this is a photoshop job, but I am always again surprised what
people do with rev (blending, masking, etc.). Or any externals for Mac and
Win? I don't know if at all it would be possible, to find and select
automatically the "background" (e.g. select always the topleft corner) and
select all of the blue, like photoshops wizard selecting tool with some
tolerance of 10 or 20%, because the RGB isn't that plain over the whole
background.


and

stephen barncard stephenREVOLUTION2 at barncard.com answered:

you mean you want a "magic wand" or "replace color" tool? I don't 
think rev

can do that natively. Adobe may even have a patent on it.



I think "to replace a color in an image" is one of the simpler tasks 
feasable with Rev (see farther below for the recipes).


There are some on this list that have explored possibilities of image 
editing with Rev - and from which I have learned much when I started 
myself to experiment with such things. Some of the results and related 
image-manipulating tools can be inspected on my website


<http://www.sanke.org/MetaMedia>.

The two "Imagedata Toolkits" from 2006 and 2007 contain more than 
hundred filters and other tools to manipulate images. A number of newer 
stacks are still in the process of being prepared for public release.


The basic problem with using Rev for image processing is that with 
big-sized images the processing speed can be very, very slow. Another 
problem are a number of bugs in Rev that led to rather frequent crashes 
when I was working on a set of other tools ("Photo Patchworks", 
"Gradientology", "Kaleidoscope Tool"), which has substantially delayed 
their release - along with the fact that Rev is no longer in the center 
of my interests as it has been before.


I have addressed the speed and crash problems on various occasions and 
also in my last post to this list of March 9: "Language comparisons: 
"Lua" - simpler and faster than RevTalk?" (which you can also get from here:

<http://www.sanke.org/MetaMedia/LanguageComparisonsLua.rtf>)

and in which I announced two other stacks "Exploring Hues" and "Lua 
Filters". Both stacks contain "replace" tools, one that I ported from 
Lua and others that I had developed earlier on my own.


Concerning Tiemo's question:

I replaced (a range of) colors colors in two images in two different ways:

1. Replacing a color range with a "plain" replace color

2. Replacing a color range while preserving "structures" in the color 
area being replaced, for examples the clouds on the blue sky that now 
look red like the replaced color of the sky, but remain discernible 
inside the new red background.


Two examples for each approach:

<http://www.sanke.org/MetaMedia/Town-original.jpg>
<http://www.sanke.org/MetaMedia/Town-RedBG-plain.jpg>

and
<http://www.sanke.org/MetaMedia/Landscape-original.jpg>
<http://www.sanke.org/MetaMedia/Landscape-RedBG.jpg>

You find the necessary scripts here:

<http://www.sanke.org/MetaMedia/ReplaceScripts.rtf>

The procedures to replace the colors in this case are like here (many 
other approaches are of course possible).


- select a color-to-be-replaced by clicking on the image and getting the 
"mousecolor" using a script in the image


- define a "range" for that color via an ask dialog

- get the replace color from somewhere; in my case I used a color field 
whose background colors I set with RGB sliders - as in the "Color 
Chooser" stack.


- finally press the replace button (and repeat that process if necessary 
to refine color selection and range).


I also use a movable graphic on top of the image to restrict such 
"replace color" (or any other) effects to a specific area of the image.


Kind regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Language comparisons: "Lua" - simpler and faster than RevTalk?

[Wilhelm Sanke]

ev to find out 
where you have to put in 255 for 1.


=

Stack "Imagedata Toolkit" already contained a number of ported Lua 
filters, among them "Kuwahara", "Jitter", and "B-contrast". The Lua 
"B-contrast" algorithm was later also used by Mark Waddingham as an 
example in his tutorials (in one of the Rev Newsletters) to build externals.


In the meantime I have collected about twenty more Lua-filter scripts 
from various sources and ported them to Rev. I am working on a "Lua 
filters" stack which will be released shortly. The stack will contain 
image filters like "dynamic range", "pixelate", "bayer", "color 
diffusion", "flip & mix", "half lua" (image inside image), "threshold", 
"atmosphère lunaire", "negative", "night vision", "grid", "sunset 
gradient", "quad mirror", "replace colors", "lua blur", "jitter-blur", 
"duotone" etc. along with additional filters developed from or inspired 
by Lua algorithms - "tritone", "quadtone", "relief grid" and other 
variants.--


What about a "Lua" plugin for Rev as in "Gimp"?

Thank you for your patience - in case you read this text up to this point.

Kind regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Our place in Hawaii....

[Wilhelm Sanke]

On Wed, 10 Feb 2010, Sivakatirswami  wrote:


Some may wonder where we are and what it's like here. A recent visitor,
with a high end camera did an amazing job and I could not resist putting
this into an iRev slide show.

http://www.himalayanacademy.com/slideshows/aadheenam/2009/ka_2009-12-30_thushyanthan-aadheenam/



Thanks for the pictures.

Works fine here - slideshow and music - on Windows with the "SeaMonkey" 
browser, the successor of Netscape.


Some time ago I stayed quite near to you for a week at "Plantation Hale 
Suites" also at Kapaa, now Best Western, on my way to work for 
several months in South Korea.  I vividly remember the beautiful 
landscapes and beaches of Kauai and especially the Waimea Canyon, the 
"Grand Canyon of the Pacific".


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Not quite [OT]: News about Revolution

[Wilhelm Sanke]

/Kay C Lan lan.kc.macmail at gmail.com wrote:

/> Following the example of "Butterfly", I would recommend to rename 
"Runtime

> Revolution" to "Runtime T-Energy".
>
 Well, just as long as the promo doesn't include:

the fastest most explosive rubbers in our line all without the use of any
speed-glues/



You are right. I overlooked this part of the text on the Butterfly 
website. Sounds like a recipe for a shoe-bomber.

I will write to Butterfly about this.

Wilhelm Sanke
/
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Not quite [OT]: News about Revolution

[Wilhelm Sanke]

First the bad news:

The European Commission has signed the Swift-Treaty with the U.S.A. that 
entitles American authorities to monitor any kind of money transfer 
inside the European Union and between Europe and the rest of the world. 
The European Parliament in its majority was against this treaty, but 
under the old law (until Dec 1, 2009) could not participate in that 
decision and now, however, might repeal it in the near future. The 
European representatives are presently under great pressure from the 
side of U.S-lobbyists, as the press reports.
The possibility to collect and screen financial and personal data has 
far-reaching consequences not only for industrial espionage, but also 
for individuals.
I could, for example, get into trouble on my next visit to the U.S.if I 
would renew my license for "Revolution" (happily I have done that 
already) or buy some add-ons out of the Revolution mega bundle. "Runtime 
Revolution" might be even worse as it suggests an immediate threat and 
an especially aggressive kind of revolution.-


Now a bit of good news:

"Andro", the manufacturer and provider of table-tennis equipment has 
produced a new rubber called "Revolution" and "Revolution Quad" with its 
varieties 420, 450, and 480 (watch for line breaks in the link).


<http://www.tabletennisdb.com/table-tennis-rubber.php?id=andro-revolution-quad-420>

The idea of the new material is to increase speed and spin, while at the 
same time maintain a high degree of control, a problem that is difficult 
to resolve because usually when increasing speed you loose control. 
Unfortunately, this new product - at first tried out widely in the 
table-tennis community - did not live up to the promises of Andro and 
the expectations of the users, which especially can happen when you 
choose such ambitious names like "Revolution" that have rather to be 
understood as an intended goal (to be reached somewhere in the future) 
than an already overall perfect and innovative tool.


Happily "Butterfly", the Japanese manufacturer with a long tradition of 
high-quality products, stepped in here. I myself had started my career 
with the legendary English "Barna" rubber (comparable to the "Basic" of 
programming languages), and then for a long time of my development used 
Butterfly "Sriver" and "SuperSriver".
Now "Butterfly" has presented the new "tenergy" rubber in several 
varieties that indeed seems to fulfil what Andro had promised with its 
"Revolution".


<http://www.butterflyonline.com/online_store_productcloseup.asp?page=rubber_all.asp&type=3&ID=97&pg=1&SortBy=b.image3&displayNum=5&frompg=allrubbers>
(again watch for line breaks in the link).

"Tenergy" is now the material of choice among most of the high-level 
players in our region. As for myself, I did not totally abandon 
"Revolution", but use it on the backhand side of my second racket which 
I use when I encounter an opponent in our team-sport series who is even 
quicker and more offensive in his play than myself - by then slowing 
down the tempo of the match with a thinner layer of "Revolution",  thus 
preserving at least a chance to survive.-


Conclusion:

Following the example of "Butterfly", I would recommend to rename 
"Runtime Revolution" to "Runtime T-Energy".


On the hand this would protect us against unwarranted harassment from 
the side of the CIA, on the other hand it would preserve the notion of a 
product that is strong, potentially reliable, and even innovative.


Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [VOTE] Tool Palette dissapear randomly Report #8500

[Wilhelm Sanke]

Richard Gaskin ambassador at fourthworld.com wrote:


Wilhelm wrote:
> On my medium-sized screen there is ample room besides the Rev tools
> stack to accommodate two open script editor windows side by side, so
> there is really no need to hide the tools stack in the default
> preferences settings.

At the heart of this issue is the question:  What would one expect to do
with layout tools while in a script editor?

That an IDE would dynamically provide progressive disclosure of features
specific to the task at hand isn't a bad thing, IMO.

But most importantly, as you noted, if it does it must do so reliably.
--
  Richard Gaskin


and Jim Ault wrote:


I use the Rev 3.5 IDE editor for my development (single pane, multi-
tabbed)
Most all of my programming is scripting (and not layout or GUI work),
so I only need the tool bar on rare occasions.  I prefer it to hide
when the script editor is open, but always show the message box. (as a
debugging tool)


I agree that the matter of individual programming habits also plays a 
role in our discussion - and that there may be only rare occasions to 
use layout tools at the same time you edit a script, but the tools 
palette also contains the two buttons to switch between browse and 
pointer tool.


In some situations I like to test immediately the effects of a changed 
script - leaving the script editor open while testing. To do this I 
usually switch to the browse tool with one click on the icon on top of 
the tools stacks - being conditioned additionally to such a procedure by 
mostly using the Metacard IDE.
 As I have found out now, in case the tools stack has been hidden, I 
could also switch to browse tool using the "tools" menu in the menubar, 
although with *two* clicks - and  I also could bring back the tools 
stack at once clicking on the tools menu.


What I like less about these niceties added with version 3.5, i.e. 
hiding the tools palette when the script editor comes up and allowing 
only one script editor in the default preference settings, is that these 
changes again increase the complexity of the Rev IDE, providing more 
opportunities for programming errors and bugs which may necessitate new 
workarounds and bug fixes - and also may add to the relatively slow 
"responsivness" of the Rev IDE (as I have pointed out in an earlier post).


If at least the default settings for the script editor preferences would 
be exactly the other way round ( I repeat myself here), Alejandro Tejado 
would probably never have run into that embarrasing situation while he 
tried to promote the revolutionary achievements of our preferred 
programming environment during his teacher workshop.


To come back to individual programming styles. I personally would have 
missed really nothing when the discussed IDE changes had not been added, 
and I suppose that most of us haven't missed them either during the last 
ten years (although I have to concede here that this is not a 
progressive and totally compelling argument, because it could rule out 
possible and real improvements).


Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [VOTE] Tool Palette dissapear randomly Report #8500

[Wilhelm Sanke]

Kay C Lan lan.kc.macmail at gmail.com wrote:
> "- If you edit a script and close the editor with the close icon - 
instead
> of the compile button - the tools palette (which disappears when you 
open

> the script editor) will not re-appear.",
>
>  i.e. after you have made a change to the script and then do *not* 
use the

> "compile" button, but the close box instead.--
>
> I still think the default preference settings for using the script 
editor
> should be exactly the other way round: Leaving the palettes in their 
place

> and allowing multiple open script windows.
>
>
 Whilst it's nice of you to post that info here, I hope you have 
included it
in a post to the RQCC, maybe as a comment to Alejandro's #8500 bug. 
Will be

fixed much quicker that way.



Done.

Regards,
Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [VOTE] Tool Palette dissapear randomly Report #8500

[Wilhelm Sanke]

On Fri, 18 Dec 2009, Richard Gaskin  wrote:


Wilhelm wrote:
> > What is really gained by hiding the tools palette when the script 
editor

> > comes up - and it seems to me to be not only a matter of preferences,
> > but a real bug, that the tools palette does not reappear when closing
> > the editor via the close icon?
> >
> > Both presently existing defaults are cases where the workflow is
> > needlessly interrupted, and could be taken as examples for needlessly
> > increasing the complexity of the Rev IDE.

One man's lost productivity is another man's productivity gained. :)


This may apply in cases, but probably not generally.


My custom script editor hides palettes when it opens a script because
those palettes aren't used in scripting and just obscure the scripting
window I'm now in.


On my medium-sized screen there is ample room besides the Rev tools 
stack to accommodate two open script editor windows side by side, so 
there is really no need to hide the tools stack in the default 
preferences settings.


Instead of hiding the tools palette, a better way to deal with this 
issue (in those rare cases where a visible tools palette could be 
considered as obstructive) would be to set the systemwindow property of 
the tools stack to false, which would enable the script editor window to 
be placed on a layer above the tools palette.



But of course once the script editor is closed or minimized, all those
layout tools need to come back reliably.


As Alejandro Tejado has stated when he started this thread, this is 
apparently not the case, those layout tools *need* to, but actually do 
not come back reliably



I just briefly tested Rev 4 and when I closed the script editor from the
close box it brought back the tool palettes.  I may have missed a step
to reproduce that, and of course if you can post a reproducible recipe
to the RQCC it should be fixed ASAP (it probably won't take long to do).
--
  Richard Gaskin


I had indicated the reproducible steps in my post of Dec 15 (thread "Rev 
IDE vs MetaCard IDE" ):


"- If you edit a script and close the editor with the close icon - 
instead of the compile button - the tools palette (which disappears when 
you open the script editor) will not re-appear.",


 i.e. after you have made a change to the script and then do *not* use 
the "compile" button, but the close box instead.--


I still think the default preference settings for using the script 
editor should be exactly the other way round: Leaving the palettes in 
their place and allowing multiple open script windows.


Best regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [VOTE] Tool Palette dissapear randomly Report #8500

[Wilhelm Sanke]

On Thu Dec 17, 2009, J. Landman Gay jacque at hyperactivesw.com wrote:


Alejandro Tejada wrote:
> Today, while teaching how to use RevMedia 4.00 v950
> to a group of teachers, the tool palette dissapear
> and sometimes reappear when users click at the
> open stack. Sometimes, the tool palette completely
> dissapears and it was necessary to close the IDE and
> restart RevMedia to use again the palette.

Look in the preferences, in the Script Editor pane, to make sure that
the palettes are not hidden when the script editor is open. The default
setting is to hide them. When you click on the stack, they come back.

--
Jacqueline Landman Gay 



Jacque,

you had mentioned this possibility to solve this annoyance by setting 
the behavior in preferences also when responding to my contribution to 
thread "Rev IDE vs MetaCard IDE" of Dec 15 - including the advice to 
change preferences for multiple script windows if needed.


Question is, should the default behavior in both cases not be the other 
way round?


What is really gained by hiding the tools palette when the script editor 
comes up - and it seems to me to be not only a matter of preferences, 
but a real bug, that the tools palette does not reappear when closing 
the editor via the close icon?


Both presently existing defaults are cases where the workflow is 
needlessly interrupted, and could be taken as examples for needlessly 
increasing the complexity of the Rev IDE.



Best regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev IDE vs MetaCard IDE

[Wilhelm Sanke]

I do not care too much how the historical icons look, what I care about 
is the functionality of the Metacard IDE. Above all I like the quickly 
accessible "Control Browser", which is my main tool during programming. 
Also: No interference from front- or backscripts in the IDE.


The workflow - for my needs - is fast, and this is not only because I am 
used to the MC IDE.


The Rev IDE has improved considerably and gradually over time. In the 
beginning it was nearly un-usable, especially with stacks that contained 
a larger number of objects, so you had to produce your own tools for 
specific purposes. What I like most of the present Rev IDE is the 
Dictionary.


Still, there are points that could be improved. A few examples.

- Response speed of the Rev IDE is sometimes slow:
   When the menubar comes up (on a 3 GHz Windows computer), first a 
blank rectangle is shown, after which menuitems and icons apppear.

   Opening menus is especially slow with cards that contain many controls.

- You can have open only one script editor at the same time in the Rev 
IDE, the Metacard IDE allows any number of open script editors (which 
simplifies the comparison and editing of scripts)


- If you edit a script and close the editor with the close icon - 
instead of the compile button - the tools palette (which disappears when 
you open the script editor) will not re-appear. You have to take a 
detour now to bring back the tools palette, for instance using the 
message box.


- Using the Property Inspector, which comes up with a noticable delay, 
and accessing the script needs one step more than in the Metacard IDE. 
But of course, using right-click on an object for getting at script and 
properties is the same in both IDEs.


- Using Rev's Standalone Builder with larger stacks was a nightmare 
until recently (including IDE version 3.5). With some stacks the 
Standalone Builder needed 45 minutes and longer to build the standalone 
- as opposed to one second in the Metacard IDE. Happily this has been 
fixed now with version 4.0, and it should be mentioned that this 
improvement was initiated and supported by a discussion between Oliver 
Kenyon and Metacard users.-


The group of Metacard IDE users - all of which are Rev Enterprise 
license holders - are naturally interested in the further improvement 
and development of Revolution (both the engine and the IDE) and some 
group members have made valuable contributions to this development. This 
is not only because the Metacard IDE - in the same way as the Rev IDE - 
needs and uses the Revolution engine (which, by the way, originated from 
the old Metacard engine). New Rev features are usually integrated into 
the Metacard IDE, too. At present there is work in progress to adapt the 
Metacard IDE to the new standalone building process of Rev.-


Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: get the color of this card at x,y

[Wilhelm Sanke]

"Bill Marriott"  wrote:


That code didn't work for me ... Probably need something more like,

lock screen
put the screenmouseLoc into coord
set the screenmouseLoc to 350,350
put the mousecolor
set the screenmouseLoc to coord
unlock screen

Alternately, one can export snapshot consisting of a single pixel and 
parse

its contents.

Wilhelm Sanke wrote"
>> >> get the color of this card at x,y
>> >>  and I would expect it to contain r,g,b
> >
> > "click at x,y
> > put the mousecolor"



You are right.
My test here was too quick, but the two-liner worked for me, because the 
point I had chosen for the test was inside an image whose script 
contained "put the mousecolor", as I now found out.


For your solution I would recommend to add "globalloc()" to easier 
access points on the card, like


  "put 545,410 into tloc
  lock screen
  put the screenmouseLoc into coord
  set the screenmouseLoc to globalloc(tloc)
  put the mousecolor
  set the screenmouseLoc to coord
  unlock screen"

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: get the color of this card at x,y

[Wilhelm Sanke]

On Thu Nov 19, Generic Email generic.email.30022 at gmail.com wrote:


I am looking for a function that does something like this:

get the color of this card at x,y
 and I would expect it to contain r,g,b

I have searched through the Revolution Dictionary, and the best I can 
find is mouseColor. This has the undesirable effect of having to move 
the mouse to the point I am checking, and the possibility that the 
user is jerking the mouse and I get the wrong color. Any ideas on how 
to accomplish this would be appreciated.



"click at x,y
put the mousecolor"

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: First test for Infinite Zoom

[Wilhelm Sanke]

Alejandro,

I finally found the time to look at your "Infinite Zoom" stack. After 
some changes to your code - I hope they were the right ones, i.e. not 
being counterproductive to your own intentions - I managed to start your 
stack, but using 6 images of my own in a folder "images"


I understand that in your stack "Zoom_infinite.rev" you "zoom out" a 
sucession of images in a stepwise fashion to achieve a decreasing size 
of the images which finally converge towards an "infinite" point, and 
after that you start all over again with a big-sized image.


At first, before I had tried your stack, my understanding had been that 
your perspective was how to implement an "infinitely" continuing zoom 
into or out of images (the latter of which, decreasing the size of an 
image until it vanishes, would be of course quite simple). I therefore 
looked at a number of scripts for (proportional) resizing of images I 
had tried in various image-processing stacks.


What I am going to mention here, may well beside your specific point of 
view concerning "infinite zoom" and meet with limited interest from your 
side.


Nevertheless, here are some observations mainly concerning "infinite 
zooming in":


1. The only procedure with which you can really "zoom-in infinitely" 
into an image is to take a continuing and everlasting succession of 
snapshots from a smaller rect of an image.
Place a rectangle graphic (the graphic can be even hidden) on top of an 
image that has its "Lock Location" set to true (to preserve the size of 
the image) and then apply the following two-liner:


on mouseUp
  put the rect of grc "select" into trect
  export snapshot from rect(trect) of img "test" to img "test" as PNG
end mouseUp

You could also put the snapshot line inside a repeat loop to achieve a 
stepwise zooming-in effect remotely similar to the effect in your stack, 
but in this example with only one image. The "quality" of the zoomed-in 
images will of course depend on the set "resizequality" of the image.
Although you indeed could continue such a procedure "forever", it makes 
sense only up to a certain point.


2. On the "slides page" of my stack

<http://www.sanke.org/Software/ThumbsAndSlides09.zip>

you can enlarge or shrink the selected images proportionally in steps. 
If - when enlarging and therefore "zooming in" in the visible windows - 
you reach a size of about

  width = 18000 pixels, height = 14000 pixels
Revolution will crash immediately and silently without an error message, 
simply vanishing from the screen, stack and IDE (Tested on WindowsXP 
with Rev 3.5 and 4.0).


3.On the slideshow card of my old sample stack

<http://www.sanke.org/Software/SlideShow-Win.zip>

you can smoothly and proportionally zoom in and out of an image using a 
slider. I have restricted the maximal size here to about 3000 x 2500. 
The smoothness of the zooming procedure ist best with the resizequality 
set to "normal". "Good" for the resizequality is still smooth and 
tolerable on a fast computer, with "best" the zooming process begins to 
slow down considerably in the upper size range.


To test the "crash limits" found above in example 2 I put an image and a 
zoom-slider on a card  - with the end value of the scrollbar set to 
19000 and zooming an image with equal values for width and height.


With "normal" resize quality the zooming was nearly smooth up to the 
value of 4000. Above 4000 the zooming process became increasingly more 
jerky.
With the resizequality set the to "best", zooming above 4000 was 
virtually impossible, whereas zooming stepwise in the "ThumbsAndSlides" 
stack occurred without a noticeable time lag even with resizequality 
"best" and up to the crash size of 18000 X 14000.


When using the zoom-slider, the crash of Rev - as described above - 
occurs at an image size of about 16000 X 16000, meaning that Revolution 
can "accommodate" images up to 256 million pixels, at least if there are 
blown up to such a size inside Revolution.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parsing images out of .ico files

[Wilhelm Sanke]

On Wed Oct 7, 2009, Monte Goulding monte at sweattechnologies.com wrote:


Wilhelm Sanke wrote:
> I just - two minutes ago - mentioned you name and successful efforts  
> on the Metacard list (subject "Standalone Builder").-


> Building time for standalones can rise to  
> several hours in the case of stacks with a larger number of  
> controls. See also my two recent contributions to thread "Practical  
> limits on object counts".


I'm no longer involved in development for the nice folks in Scotland.  
You will need to take up any issues with them now.


Cheers



Monte,

I found the post of 5 years ago mentioning your valuable work in 
improving the Rev standalone-building process.


On Sept 20th, 2004,  I had written to the improve-revolution list:

Subject: New troubles with standalone building and players for 
multi-fields stacks


 The tests described below were conducted on a Windows XP machine with 
2.5 GHz.


The standalone build time for my 3300-fields teststack was down to 20 
seconds when Monte Goulding had modified the standalone builder of 
version 2.2B1 on March 5. With version 2.5R2 build time has again 
reached an extreme length of 40 (forty) minutes. CPU use during the 
build time is 100%. Build time with the Metacard Standalone Builder is 
1 second!


It would be nice if the nice folks in Scotland would take a look at your 
script.


I also sent another post to the improvement list today and added a new 
commentary to bug 2217.


Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Parsing images out of .ico files

[Wilhelm Sanke]

On Wed Oct 7, 2009, Monte Goulding monte at sweattechnologies.com wrote:


>
> You must have been looking in the MC IDE, right? The Rev one is  
> protected.

>

Now you're showing your age. The Rev one hasn't been protected since  
the security was put back into the engine where it belongs. Take a look.


Cheers

Monte



Monte,

I just - two minutes ago - mentioned you name and successful efforts on 
the Metacard list (subject "Standalone Builder").-


What is unprotected - in version 4.0-dp4 - is stack 
"RevStandaloneSettings" - maybe the icon question is solved there?


Substack "revSavedAsStandalone" is still protected, which has hindered 
resolving some problems with standalone building since a number of 
years, apparently and especially the processes of removing "development 
properties". Building time for standalones can rise to several hours in 
the case of stacks with a larger number of controls. See also my two 
recent contributions to thread "Practical limits on object counts".


Best regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Practical limits on object counts

[Wilhelm Sanke]

Yesterday I had written in response to one of Richard's post of this thread:


Responding to your post, I have expanded my test stack of 2004 to now
containing 1 (ten thousand) fields.

(was: <http://www.sanke.org/Software/RevTestStacks.zip> for the 
3300-fields stack)


I will post the URL of the new test stack in my next post to this list.

Preliminary results of testing with the 10,000 fields' test stack:

Creating the 1 fields takes around 200 seconds in the Rev IDE, 130
seconds in the MC IDE.
Deleting the 1 fields in the Rev IDE takes 420 seconds in the Rev
IDE, 6 seconds in the MC IDE

The three buttons for creating color patterns need about 2.3 seconds in
the MC IDE, 3.5 seconds in the Rev IDE

When the 1 fields have been created, the Rev IDE is very much
unresponsive, no Problems with the Metacard IDE (with the exception of
the Metacard "Control Bowser" which needs also more time to respond when
1 fields are present)

I did not yet test to build standalones.


The figures quoted above were measured on a 3 GHz WindowsXP machine with 
Rev engine versions 4.0-dp4.


The problem back in 2004 with the 3300-fields' stack was the intrusion 
of a front- or backscript concerning only table fields, but because this 
script was insufficiently "isolated" to only monitor "table fields", it 
therefore constantly monitored any kind of fields.


Such well-meant, but in many cases unneeded interference from front and 
backscripts is still a very negative characteristic of the Rev IDE. The 
Rev IDE has a very "interrelated", "intertwined" structure. This has 
been discussed several times in the past with proposals to achieve more 
"modularity" in the Rev IDE, to make a number of parts of the IDE more 
independent of each other.
The present format has reached such a level of "interrelatedness" that 
the Rev IDE will cease to function completely when you remove certain 
front or backscripts ( I tested this, but do not remember at the moment 
which of these scripts were the culprit).


There may be well also limits located in the engine, but as there are 
clearly to be seen differences between the performances of the Metacard 
and Rev IDEs, it is worth while also to think about improving the Rev IDE.


One thing the Rev IDE does is to add so-called "development properties" 
to each object that is being created. This process in its result slows 
down the creation of objects and the overall performance of the IDE when 
a certain number of objects has been reached - as Richard found out: 
around >5000.


I now have tested to create standalones from my new 1-fields stack:

Metacard IDE: Creating the standalone took less than one second!
I have to add here that I had to use the "Standalone" file of Rev 
version 3.5, the file of the 4.0-dp4 version did not work with the 
Metacard IDE, presumably a bug.


Rev IDE: I canceled the test after 40 (forty) minutes. The Rev IDE then 
was still working on "Removing development properties", but without a 
final result.
Before I started the standalone builder I had unchecked "Search for 
required inclusions" ( as there were none ) and to add any dialogs or 
library inclusions.


In section "Property Profiles" of the standalone settings unfortunately 
you cannot uncheck all of the options, you have to choose from at least 
one of them. So I chose "Remove all profiles on objects" although I 
really was not interested to achieve this special goal.


After about ten minutes of standalone building the Rev window panes 
turned completely black and after some time returned to normal. After 40 
minutes there was no way to remove the blackness of the Rev Windows, and 
then I force-quit the standalone building via the Windows Task Manager.-


Another observation:

To use less space on the card containing the 1 fields I set the 
width and height of the template field to 4. This worked fine in the 
Metacard IDE when creating the fields.


In the Rev IDE however the size of the created fields - despite the 
template settings of 4 - was a width of 250 and a height of 57 for each 
of the 1 fields.
I found out that this occurs with all template field settings <9 - 
another instance of a unwanted and unneeded intrusion from the side of 
the Rev IDE.


To be able to precisely compare the performances of Metacard and Rev IDE 
I therefore  chose "9" for the template field settings in my test stack.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Practical limits on object counts

[Wilhelm Sanke]

On Sat Oct 3, 2009, Richard Gaskin ambassador at fourthworld.com wrote:


Maybe it meant "Too many for the IDE to display", since it seems the
engine is fine. :)

I wonder exactly what their threshold is for "too many", and how they
arrived at it when they wrote their IDE.

The more I played around with my tests, the more I see a very dramatic
difference in responsiveness beyond a certain threshold somewhere beyond
6,000 objects.  I haven't yet pinned it down exactly, but definitely
10,000 is beyond acceptable for most uses, so it's somewhere between 6k
and 9k.

The difference between 6k and 9k objects is so dramatic that I have to
wonder if there's some aspect of how the engine's memory mapping or
object hashes were written that may play a role in the sharp performance
degradation.

I dunno.  I just know not to try working with 9k objects. ;)

--
  Richard Gaskin



Richard,

Back in 2004 we had a discussion on the improve-list very much about the 
same problem. At that time The Rev-IDE was unable even to cope with 
cards that contained around of 3000 objects. The Metacard IDE had no 
problems with this. Creating a standalone in the Rev IDE lasted 
"forever", again , no problem in the Metacard IDE.


Here is some of the relevant text on my "RevTestPage" 
<http://www.sanke.org/RevtestPage> from 2005:



Revolution Test Stacks

Following the recent discussion about the "RevTable bug" (Bugzilla 
2019) and Standalone Builder problems (Bugzilla 2217) on the 
improve-revolution list (August/September, 2004) I add two stacks


<http://www.sanke.org/Software/RevTestStacks.zip>

and a readme file for interested testers of the Revolution IDE that 
demonstrate the bugs and related problems with stacks that contain 
larger number number of controls, especially larger number of fields. 
Details - i.e. the complete bug reports of Bugzilla 2019 and 2217 - 
are to be found by clicking the "readme"-buttons of the test stacks, 
which however when opened in the Rev environment need some time to 
display the contents of the connected field in the larger 3300-fields 
stack that may bring down the Revolution IDE almost to freezing point 
on medium-fast computers.


Read below what has been fixed in the meantime:

All the described problems do not appear when the stacks are opened in 
the Metacard IDE. You can test this by downloading the Metacard IDE 
(1.4 MB zipped) from here.


Thanks to the continued efforts to improve Revolution some of the 
described problems have now been resolved with version 2.5.1. (March 
2005). The speed of the test stack is now almost identical in both 
environments with even a small advantage for Revolution - when run in 
the development environment..


However, the problem of building a standalone of this stack 
unfortunately has not dealt with successfully even with Revolution 
version 2.6 (June 2005). Building the standalone in the Rev IDE takes 
"forever", whereas building a standalone of the test stack with the 
Metacard "Standalone Builder" takes less than a second. (see comments 
in Bugzilla 2217).


Version 2.7-GM-1 of Revolution (February 2006) has also not yet 
resolved this standalone-building problem.
  


Responding to your post, I have expanded my test stack of 2004 to now 
containing 1 (ten thousand) fields.


I will post the URL of the new test stack in my next post to this list.

Preliminary results of testing with the 10,000 fields' test stack:

Creating the 1 fields takes around 200 seconds in the Rev IDE, 130 
seconds in the MC IDE.
Deleting the 1 fields in the Rev IDE takes 420 seconds in the Rev 
IDE, 6 seconds in the MC IDE


The three buttons for creating color patterns need about 2.3 seconds in 
the MC IDE, 3.5 seconds in the Rev IDE


When the 1 fields have been created, the Rev IDE is very much 
unresponsive, no Problems with the Metacard IDE (with the exception of 
the Metacard "Control Bowser" which needs also more time to respond when 
1 fields are present)


I did not yet test to build standalones.

So far for now.

Best regards,

Wilhelm Sanke
Prof. emeritus
University of Kassel, Germany
Education/Educational Technology
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Script Editor - slight snag

[Wilhelm Sanke]

J. Landman Gay jacque at hyperactivesw.com wrote (Tue Sep 22 21:58:56 
CDT 2009):




Wilhelm Sanke wrote:

> Another issue when using the script editor is that the tools stack can
> vanish when editing a script and can only be brought to life again when
> you type "choose browse tool" into the message box. This happens if you
> do not click at the "compile" button, but close the script editor with
> the "close" icon.

In Preferences, in the Script Editor pane, do you have "Hide palettes"
unchecked?



I did not change anything in preferences, I just used the default 
setting which has "Hide Palettes" and "Hide Message Box" checked "when 
editing scripts". But even with these settings the tools stack should 
reappear after closing the script editor - which it does not, unless you 
click at the "compile" button first!


So this is still a bug!

I understand that Rev developers try to make life for users more 
comfortable, but contrary to their intentions sometimes make things more 
complicated.

The default setting should in any case be the other way round.-

The same holds for the other issue Richmond raised - now having only one 
script editor open at the same time as the default.


Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Script Editor - slight snag

[Wilhelm Sanke]

On Tue Sep 22, 2009, Richmond Mathewson richmondmathewson at gmail.com 
wrote:



When I was working with DreamCard 2.6.1
(i.e. until sometime in August) I could open
the script of 2 objects side by side for
comparison purposes or otherwise.

This doesn't seem possible in RR 4.

It seems that there is only one script-editor
window.

Am I missing something?



I filed a bug report about this on Sept. 14.

See

<http://quality.runrev.com/qacenter/show_bug.cgi?id=8272>

Another issue when using the script editor is that the tools stack can 
vanish when editing a script and can only be brought to life again when 
you type "choose browse tool" into the message box. This happens if you 
do not click at the "compile" button, but close the script editor with 
the "close" icon.


Richmond, be so kind as to file this special bug?

Best regards,

Wilhelm Sanke

 
___

use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Groups: Bugs and features ("last group" broken)?

[Wilhelm Sanke]

On Wed Sep 16, 2009, DunbarX at aol.com DunbarX at aol.com wrote

Yes, I ran into at least one of your issues back in May. Check out the 
"New

groups bugaboo" thread in the archives.

Eventually I was led to a very cool feature (by Scott Rossi), the
"templateGroup". Check this out. It is very stable. This is something 
solid; using
the somewhat ephemeral "last" keyword as a hard tool always seemed 
like a very

cute, but a little dishonest, methodology.

Apparently this is only a problem with groups. The "last" keyword works
fine with, say, buttons.

Craig Newman


Thanks for the confirmation of one of the group issues I listed in my 
post. I must have missed the thread in May being out of office and 
country at that time.


Using Scott's "templategroup" proposal may be handy when only one group 
building is involved.


In the case of my "Gradient Kaleidoscope" scripts I have to make 
frequent use of grouping and ungrouping (the last group) of images, and 
I find it easier and more convenient to use the workaround with finding 
the "owner" of one of the controls that have been grouped, as in -  I 
quote myself here -


 "select fld "one" and fld "two"
 group
 put the owner of fld "one" into tlastgroup"


Best regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Groups: Bugs and features ("last group" broken)?

[Wilhelm Sanke]

 "test" 
to an angle other than 0, that img "test" is ungrouped, and that img 
"Test" belongs in the category of "Pre-PNGs".


 "lock screen
 select img "Test"
 group
 set the angle of img "Test" to 0"

For the definition of "Pre-PNGs" see my above-mentioned post or the 
introduction to my stack


<http://www.sanke.org/Software/MoreAboutMasksRev3.zip> in the text 
brought up on the menu card from the topright introduction button.



Seems to me, there is some work to do from the side of the Rev 
developers. I hope I have contributed something to start with.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines

[Wilhelm Sanke]

On Wed Aug 26, 2009, Björnke von Gierke bvg at mac.com wrote:


  On 26 Aug 2009, at 22:45, Wilhelm Sanke wrote:

> 

maybe sending this to the runrev guys/gals via bugzilla err  
quality center would be more advantageous in regards to getting the  
crashes fixed?


This is intended.

As there are presumeably quite a number of factors involved that 
contribute to crashes and irregularities in image and graphics use,  
"fixing" the causes may not be an easy and quick task. I have the 
impression that a general overhaul of this part of Rev would be needed.


On the other hand, sending such posts to the use list can be very  
therapeutic, as i can attest from my own experiences ;)



You are right here. After such a long time of fishing in the dark, I was 
really pleased and relieved to have at least found one instance, where I 
could safely reproduce a crash and list the involved Rev elements.



To bad that you can't even attend edinburgh via the web :(

Björnke


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines

[Wilhelm Sanke]

I 
produced a test stack "Crash Recipe" which contains and isolated the 
elements necessary for a crash, and I also added a workaround.that 
avoided a crash to that stack.


First of all, the one image used in the test stack needs to be of the 
"Pre-PNG" type, an image type I have named as such and described in 
detail in my stack "More about Masks"


<http://www.sanke.org/Software/MoreAboutMasksRev3.zip> in the text 
brought up on the menu card from the topright introduction button.


"Pre-PNG" images are basically those that are created or modified (as to 
their imagedata) in Revolution and have not yet been saved as external 
files and then been re-imported. Even if you export a snapshot using "to 
image x as PNG" (image x being an image already existing on the card), 
the resulting image will remain a Pre-PNG, also copying and pasting the 
Pre-PNG to another card or stack preserves the quality of the Pre-PNGs 
which behave differently in some respects. For details see my comments 
in "More about Masks".


For the test stack I created a basic gradient image with the "Gradient 
Kaleidoscope" tool and copied it to the teststack. If you want to work 
with a test stack of your own, you could create an image in my 
"Imagedata Toolkit 
<http://www.sanke.org/Software/ImagedataToolkitPreview3.zip>" 
(preferably a gradient image) and then copy it into your stack along 
with the scripts below.


The second precondition is that "lock screen" is used as the first line 
in the four-liner, without "lock screen" no crashes occur.


Script 1 assumes that you have set the angle of img "test" to an angle 
other than 0 and that img "test" is ungrouped.


 "lock screen
 select img "Test"
 group
 set the angle of img "Test" to 0"

Script 2 assumes that you have set the angle of img "test" to an angle 
other than 0 and that img "test" has been grouped immediately before 
running the script


 "lock screen
 select last group
 ungroup
 set the angle of img "Test" to 0"

Happy crashes now! Happily with these reduced scripts you will not 
produce corrupted stacks.


One workaround to avoid the crash is to take line "set the angle of img 
"Test" to 0" out of the script and put it into a separate button 
script., let us name the button "ZeroAngle".


In Script 1 and 2 then you need to replace the last line by

"send "mouseup" to btn "ZeroAngle" in 0 milliseconds"

The most important part of the above line is "in 0 milliseconds".

I have come across such "out-sourcing" needs several times in 
image-processing scripts, also such where you need not add "in x  
milliseconds".--


I will spend an very extended weekend in "Heidelberg" on urgent business 
and also some diversions (among them anniverseries) planned long ahead, 
unfortunately preventing that I might even listen in to the Rev 
Edinburgh conference. But I wish all participants new insights and 
experiences.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

===

P.S.: Some examples of peculiarities in image and graphics processing or 
related to it:


1. Sometimes using "flip horizontal" 1/3 of a partly transparent image 
is suddenly additionally transparent.


2. Turning the mid-square of an rectangular image (width > height) by 90 
degrees (shifting the pixels by script) results in a semi-transparent 
overlay when the width of the image is odd


3. Some operations cannot be performed on an image when the ink is set 
to "notSrcCopy", e.g. replacing a color or color range by a specific 
other color


4. Exporting a snapshot to an image with a blendlevel (e.g. set to 50) 
leaves part of the former contents of the image intact.


5. With one script I suddenly happened to get groups nested 9 levels 
deep, although in the script that seemed to have produced these nested 
groups, groups were built and properly ungrouped only at two places in 
the script. The same script - without a change - never before and also 
never after this incident produced such nested groups.
The creation of these 9 nested groups was accompanied by a crash, 
question is: Did the nested groups cause the crash or did the crash 
produce the nested groups?


6. "lock screen" is sometimes disregarded (first noticed with version 
4.0-dp1, later also with 3.5) by the engine in scripts of the 
Kaleidoscope stack


7. "Pre-PNG" images are basically such that are created or modified (as 
to their imagedata) in Revolution and have not yet been saved as 
external files and then been re-imported.
>From the introductory text of stack "More about Masks 
<http://www.sanke.org/Software/MoreAb

Re: Vote to disable password protection for revMedia 4 stacks

[Wilhelm Sanke]

On Tue Aug 25, 2009; William Marriott wjm at wjm.org wrote:
 

There are many reasons why we opted to make revMedia a free product.
I'll detail some of them here:

1) Students.
(snip)
2) Ubiquity.
(snip)
3) Great content everyone can see.
(snip)
4) It's 2009 and the Web is all about FREE.
(snip)
5) Revenue.
(snip)
- Bill
   RunRev marketing guy


Bill,

I am really happy that you eventually have re-introduced a free version. 
In 2001 the Rev team strongly opposed such deliberations, mainly because 
of economical reasons.


Here is a part of my post sent to Kevin (Miller) some days ago, when I 
extended my license up to 2013.


I congratulate you on the decision to offer one version of Revolution 
to the public for free. In 2001 we both had an exchange on the 
Revolution list about such free versions. I had proposed to you to 
continue to support the Metacard version - as some sort of "Revolution 
Light" - and either offer it for free or at a very low price. Such a 
step - in my opinion - would have been necessary, because at that time 
you discontinued the free "Starter Kit" versions - from economical 
reasons as you stated it, if I remember correctly.


Not having at my disposal such Starter Kits has impeded my work to 
some substantial degree with students at our university. We were 
however  lucky to be able to continue to use the old Starter Kit 
versions (which one could extend up to version 2.5), but were of 
course unable to work with newly introduced features.-



Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Challenge: How can we set the rect of a polygon to its visual rect?

[Wilhelm Sanke]

On Mon Aug, 2009, dfepstein at comcast.net dfepstein at comcast.net wrote:


It appears that Rev defines the rect of a regular polygon to be the 
rectangle that encloses all possible rotations of that polygon.


This seems like a useful enough feature that I wouldn't call it a bug.

David Epstein


Correct observation. And what is more, this "maximal rotation rect" 
remains the same even when you change the polysides property of a 
regular polygon, switching from a hexagon to a triangle or to any other 
polygon shape.


For what purposes may such a feature be "useful"? I think it was not 
intended as a useful feature, it just "happened" during the development 
of the algorithms for regular polygons.


And again, I believe, it would not cause too much trouble for the 
developers of Revolution to define the rect of a regular polygon as a 
"minimal visual rect" that will be adapted to its minimal size each time 
the angle of a given regular polygon is being changed.


Another additional or parallel solution would be, which I mentioned in 
my last post, to make the values of the vertexes of a regular polygon 
available and retrievable, and then let the user choose to set the style 
of the polygon to "polygon" based on the given points/vertexes.


Regards,

Wilhelm Sanke


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)

[Wilhelm Sanke]

On Sat Aug 15, 2009, capellan capellan2000 at yahoo.com wrote:


Hi Wilhelm,

(snip)
Some time ago, i posted a stack named "export_regular_polygons"
than shows a formula to convert regular polygons (3 to 20 sides)
in polygons:

http://www.geocities.com/capellan2000/export_regular_polygons.zip

Wilhelm Sanke, FB01 wrote:
>
> I conclude: I think it should be a relatively easy task for the
> programmers of Revolution (or Transcript, RevTalk etc.) to abolish the
> inconsistency of regular polygons of  having different sizes for visual
> rects and their proper rects as a graphic.
>

i agree. if you fill an enhancement request in the Runrev Quality
Control Center, i will vote for it.

Have a nice weekend.

al


Hi al (or "Al" - or whatever is behind "al" - but no need to out yourself),

Amazing! Your stack indeed really "crops" a regular polygon and converts 
it to a normal polygon.


This - your approach to the conversion - was exactly what I was looking 
for and had imagined to be feasible.


I took the liberty to set the lockloc of grc "Test" to false to see how 
your script handles regular polygons when the polygon is being 
"distorted", i.e. when the angles of the regular polygon are not 
identical. In this case your script nevertheless determines the points 
for the normal polygon on the basis of an ideal shape of the regular 
polygon with identical angles, but at the same time considering the set 
angle (the possibly rotated angle of the whole polygon) of the regular 
polygon.
This "ideal" form of the converted polygon could of course then be 
distorted manually to be identical with the visual shape of the regular 
polygon. I assume this part of the conversion could also be scripted?--


Just to mention it for the sake of completeness, my own way to convert 
regular to normal polygons has been a simple "hands-on" approach - like 
in the case of cropping an image to its visual rect, which I had 
described in an earlier post:


- I either have traced the regular polygon with the free-hand polygon 
tool, which procedure needs a steady hand and in most cases later 
fine-tuning of the gained points for the polygon, or


- I clicked at the vertexes of the regular polygon ("put the mouseloc") 
to establish the points for the normal polygon, which also may need some 
fine-tuning afterwards.--


I believe that the Rev engine internally must know the values of the 
vertexes of a regular polygon, otherwise it would not be able to display 
the shape of a regular polygon, both in its ideal and distorted form.
So, the task for the Rev team to produce an enhancement that would make 
it possible to reduce the rect of a polygon to its visual rect would be 
simply to make the values of the vertexes available and retrievable, and 
then let the user choose to set the style of the polygon to "polygon" 
based on the given points/vertexes.


Best regards,

Wilhelm
<http://www.sanke.org/metaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)

[Wilhelm Sanke]

 put the topleft of grc "Test" into TL
 put the bottomleft of grc "Test" into BL
 put the bottomright of grc "Test" into BR
 put the width of grc "Test" into twidth
 put trunc(twidth/2) into twidthhalf
 #=set the points for the "free" polygon===
 put empty into tpoints
 put (item 1 of TL + twidthhalf, item 2 of TL) into tpoints
 # for the first line of tpoints "put into"
 put CR&BL after tpoints
 put CR&BR after tpoints
 put CR& (item 1 of TL) + twidthhalf, item 2 of TL after tpoints
 #
 set the points of grc "Test" to tpoints
 set the style of grc "Test" to "polygon"
end mouseUp

Now you have got a polygon that extends to the size of the full rect of 
the former regular polygon, displaying *no* differences between rect and 
visual rect.


Now add two buttons for converting grc "test" from polygon to regular 
polygon and the other way round and you can see the effects


Example 2:

Create a hexagon, a six-sided regular polygon, then use this somewhat 
more detailed script:


on mouseUp
 put the topleft of grc "Test2" into TL
 put the topright of grc "Test2" into TR
 put the bottomleft of grc "Test2" into BL
 put the bottomright of grc "Test2" into BR
 put the width of grc "Test2" into twidth
 put the height of grc "Test2" into theight
 put trunc(twidth/4) into twidthquart
 put trunc(theight/2) into theighthalf
 #=set the points for the "free" hexagon polygon==
 put empty into tpoints
 put (item 1 of TL + twidthquart, item 2 of TL) into tpoints
 # for the first line of tpoints "put into"
 put Cr& (item 1 of TL, item 2 of TL + theighthalf) after tpoints
 put CR& (item 1 of BL + twidthquart, item 2 of BL) after tpoints
 put CR& (item 1 of BR - twidthquart, item 2 of BR) after tpoints
 put Cr& (item 1 of BR, item 2 of BR - theighthalf) after tpoints
 put CR& (item 1 of TR - twidthquart, item 2 of TR) after tpoints
 put CR& (item 1 of TL + twidthquart, item 2 of TL) after tpoints
  #
 set the points of grc "Test2" to tpoints
 set the style of grc "Test2" to "polygon"
end mouseUp

Add another two buttons for converting the styles of grc "Test2" like in 
the above example.---


What is obvious is that in the first place you do not need a regular 
polygon to compute the points of a polygon without differences between 
rects and visual rects, all that you need are just the dimensions of a rect!


The calculation of the points for other numbers of sides may require  
more effort, but seems to be feasable.


I conclude: I think it should be a relatively easy task for the 
programmers of Revolution (or Transcript, RevTalk etc.) to abolish the 
inconsistency of regular polygons of  having different sizes for visual 
rects and their proper rects as a graphic.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Challenge: How can we set the rect of a polygon to its visual rect?

[Wilhelm Sanke]

On Fri Aug 14, 2009, Scott Rossi scott at tactilemedia.com wrote:


Recently, Wilhelm Sanke wrote:

> Triangles, pentagons, and hexagons (three-, five-, and six-sided
> polygons) have rects that are different from their visual rects, i.e.
> their opaque areas when the fillcolor is set to true.
>
> As an example, a hexagon with a height of 200 possesses a "visual"
> height of only 172.
>
> A snapshot taken from the graphic has the same dimensions, but the
> resulting image can be cropped to the real visual height.
>
> Cropping however is possible only with images, so how do we proceed to
> set the rect of a hexagon (or triangle and pentagon) to its visual rect?
>
> Any ideas?

You can crop a snapshot image of the graphic by looking at the 
alphaData of

the snapshot and cropping into the image only where the alphaData is 100%
transparent (or some other threshold you prefer).  I posted a stack that
does this


Scott, thanks for the answer, but this proposal is exactly what I have 
stated in my quote above. I was concerned about how to "crop" a 
*graphic* or to find some sort of workaround for this.


I have been using cropped images as masks for quite some time, one 
example being the hexagons displayed on my various "Gradient 
Kaleidoscope Galleries" (see my website below).


As regular polygons (as graphics) show this difference between rect and 
visual rect (only in the case of triangles, pentagons, and hexagons), I 
use normal "free" polygons to create triangles, pentagons, and hexagons 
as slection tools. Graphics as selection tools to cut out a section of 
an image work smoother than using a masked image for this purpose. But 
to exactly draw such a graphic hexagon requires more effort.


I wonder why this difference between rects and visual rects of graphic 
triangles, pentagons, and hexagon exists.


Is there a reason for such exceptions or do we add these inconsistencies 
to the list of peculiarities present in Revolution's graphics and image 
processing which urgently need to be eventually cleaned up?
Recently I had commented on a number of such peculiarities, which I 
suppose may contribute to the many crashes I experience with some of my 
image processing stacks.


So again, does anybody know a way - or a workaround - to "crop" a 
regular graphic to the size of its visual rect?


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Challenge: How can we set the rect of a polygon to its visual rect?

[Wilhelm Sanke]

Triangles, pentagons, and hexagons (three-, five-, and six-sided 
polygons) have rects that are different from their visual rects, i.e. 
their opaque areas when the fillcolor is set to true.


As an example, a hexagon with a height of 200 possesses a "visual" 
height of only 172.


A snapshot taken from the graphic has the same dimensions, but the 
resulting image can be cropped to the real visual height.


Cropping however is possible only with images, so how do we proceed to 
set the rect of a hexagon (or triangle and pentagon) to its visual rect?


Any ideas?

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[ANN]: Gradient Kaleidoscope Galleries (and Rev 3.5 still crashing)

[Wilhelm Sanke]

According to the logs, there were 5700 hits to my website during the 
last three days (the individual images of the galleries that have to be 
downloaded with the html pages are counted) and a data-transfer volume 
of 500 MB ensued. So there has been some interest by list members. 
Locally I got positive feedback from our College of Fine Arts, where I 
had conducted seminars in the past.


Concerning the problem of the crashes, I received a detailed commentary 
off-list outlining possible causes or contingencies.


As I see it at present, the irregular crashes could be related to image 
behavior with masks, meaning related to how the engine handles masked 
images.


The last crash occured yesterday while I was online, which caused the 
Windows system error dialog to react. The error message - as far as I 
could understand it - pointed to an "exception" concerning the engine 
and mentioned "images". I tried to get a copy of the error message and 
was informed that an error file with a cryptic name would be found in 
one of the temp folders. However, apparently because I did not forward 
the error message to Microsoft, no such file was to be found afterwards. 
Next time I will forward the message to Microsoft and see whether I can 
get hold of the error file.


I will now list here a number of peculiarities I encountered while 
working with images in Revolution, some of these peculiarities could 
probably be assessed as features, others appear to be at least 
"anomalies" or even bugs:


1.  From the text of stack "More about Masks" of January, 2009,
<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>
on the menu card accessed from the topright introduction button:
A final observation concerning the creation of masks inside Revolution 
and using the "import snapshot" format:


If the resulting mask image is not first saved as an external file and 
then imported again, meaning if it remains as freshly created inside a 
stack or was just copied from another mask-producing stack, then this 
mask image will have a different quality, which we might call a "pre-PNG".


Pre-PNGs behave somewhat differently than normal PNGs: You cannot 
transfer its alphamask to the image-to-be-masked when the pre-PNG is 
hidden, at least not several times with resizing. After you have 
resized a pre-PNG during the masking process, you might find that it 
is suddenly "empty", but it can be restored when you copy and paste it 
(it then appears in its original size and shape).
A workaround to overcome this problem is to store the mask in a custom 
property of its own and then to "initialize" the mask each time before 
it is used in the calling script:

"put the CPimg of img "transition" into img "transition""

But of course you can easily convert a pre-PNG to a full PNG by saving 
the image as an external file.
2. Sometimes when I apply "flip horizontal" to a masked image an 
additional part of the image becomes transparent, which may be followed 
by even more transparency when the image is flipped back, possibly 
leaving only a smaller middle part opaque. I did not succeed in exactly 
reproducing this behavior, like the crashes this happens quite 
unexpectedly, except that I noticed that I had used an algorithm to 
create a "diagonal mirror" of an image among the operations before the 
additional transparency appeared.


3. If  the mid-square of an image is turned by 90 degrees - as part to 
create a special effect - (shifting the pixels by script) this results 
in a semi-transparent overlay for the middle part when the width of the 
image is odd, i.e. you see both the original middle part and the turned 
middle part as if two image were put on top of each other with their 
blendlevels set to 50.


4. Some operations cannot be performed on an image when the ink is set 
to "notSrcCopy", e.g. replacing a color or color range by a specific 
other color


5. Exporting a snapshot to an image with a blendlevel (e.g. set to 50) 
leaves part of the former contents of the image intact, meaning you see 
both the former picture of the image + the image exported with the 
snapshot.--


Question is, are such anomalies in any way connected to the crashes I 
experience with my Gradient Kaleidoscope tool?  I have never encountered 
such crashes when using the "Imagedata Toolkit", but there I did not 
make use of masks.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [ANN]: Gradient Kaleidoscope Galleries (and Rev 3.5 still crashing)

[Wilhelm Sanke]

Before I answer Bernard Devlin's post below, let me mention that I have 
uploaded an additional Gallery page, this time containing only 8 images


<http://www.sanke.org/MetaMedia/GradientKaleidoscopeGallery4.htm>.

The cause why I did that is mainly that I stumbled across a phenomenon 
that was really new to me. The first picture of Gallery 4 "Floating 
Blue", blue structures on a red background, conveys the impression - 
although it is a JPEG - that it is three-dimensional, the blue parts 
floating somehow 2 millimeters above the red background.


The other seven images are kaleidoscopes based on rather fine gradient 
material (which I like very much, but that is an individually personal 
thing).--


===

On Sun Jul 19, 2009, Bernard Devlin bdrunrev at gmail.com wrote:


Wilhelm, regarding the crashes.  Have you watched the ram-usage during
the operation of your application?  Could it be that there is a memory
leak in some part of Rev that is causing the crashes.

Bernard



Thanks for the hint, Bernard.

I will try to get acquainted with "MMC", the system monitoring device on 
Windows XP. Otherwise, there are 4 GB Ram on my fairly new computer, 
which should be sufficient for the majority of applications, but 
probably not for a leaking Rev engine.
I have already tried the Windows "Task Manager" and noticed that CPU-use 
never exceeded 50% when using my stack.


What puzzles me is that the very same script may run perfectly 50 times 
in a row, and then eventually crash stack, IDE, and engine on number 51 
(or 501).


Last time when I got a corrupted stack, which I had backed up half an 
hour before the crash - I had just added two buttons to the stack that 
had run OK for a number of times.
After the crash occurred, I retrieved the scripts of the two added 
buttons from the corrupted stack with Wordpad and added the two buttons 
again to the backup stack. The very same scripts now worked without 
problems - as they should of course.--


One of the more complex scripts I use here in my gradient tool have such 
features:


- snapshots are taken 9 times
- there are 7 additional placeholder images that are manipulated behind 
the scenes

- angles of images are set 11 times
- two groups of images are created and then ungrouped again.

This type of complexity, which is really different from that of my other 
image-processing stacks, led me to the idea I had expressed in my last post


> I have not yet been able to find out the exact cause and its location 
in the
> scripts for these crashes. I have the feeling that somehow "toxic 
waste" is
> accumulating in stack and/or engine which then causes crashes when a 
certain

> level has been reached. It may well be related to the frequently applied
> procedures of various kinds of snapshot-taking, masking, setting 
angles, and

> grouping or regrouping of images.--

Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[ANN]: Gradient Kaleidoscope Galleries (and Rev 3.5 still crashing)

[Wilhelm Sanke]

As the "Gradient Kaleidoscope Tool" stack is nearing completion, but 
still crashes Rev 3.5 more or less frequently, I have uploaded a number 
of examples produced with the Kaleidoscope tool to demonstrate what can 
be achieved with it.


Either go to <http://www.sanke.org/MetaMedia> and scroll down on the 
left side until you see "Kaleidoscope Galleries",

or go directly to

<http://www.sanke.org/MetaMedia/GradientKaleidoscopeGallery1.htm>  or
<http://www.sanke.org/MetaMedia/GradientKaleidoscopeGallery2.htm>  and
<http://www.sanke.org/MetaMedia/GradientKaleidoscopeGallery3.htm>  

The examples have been produced by mainly applying two basic techniques 
- described here in a much simplified way:


1. Putting two copies of an image on top of each other, setting their 
blendlevels to 50, setting a different angle for the upper image, and 
then taking a snapshot.


2. Selecting a triangle with an appropriate base width from the original 
gradient image (or: any image of course can be used) and then arrange 
these triangles to form three-sided to multi-sided polygons.


The original image need not be an exact square, but can be of any 
different width and height. The triangle elements will be adapted 
automatically to their required height and width to fit into the created 
polygon if you have for example a "wider" or "heigher" original image.


Presently I have implemented scripted procedures in the tool stack to 
produce


- a triangle-polygon, consisting of three smaller traingles
- square, consisting of four triangles
- pentagon, 5 triangles
- hexagon
- octagon
- rotated octagon
- hexadecagon, 16 triangles
- 32-sided polygon, and
- multisided polygons.

Up from a hexadecagon it might be better to apply an oval mask, but I 
have also included hexadecagon examples with discernable sides.


The trickiest part for me was to find the algorithms for the 
triangle-polygon and the pentagon, e.g. for the triangle-polygon you 
have to compute the relative height of the smaller 3 triangles to fit 
exactly into the bigger triangle (which is roughly "width of the 
triangle divided by 3.47") and then you have to find a way to position 
the triangle parts in the script to form the respective polygon, which 
is somewhat difficult because rotated images with an angle other than a 
multiple of 90 have rects of a different size. Finally, you have the to 
find out the rect from which you need to take the final snapshot from 
the grouped smaller triangles.


A number of examples especially in Galleries 2 and 3 have a somewhat 
"naturalistic" look because they display certain irregularities that 
were brought about by different - and often repeatedly applied - 
algorithms, like skewing, mirroring, changing color values, 
enlarging/stretching, despeckling, additional gradient overlays, 
lithography, sharpen, and smoothing filters etc..


Concerning the crashes:

Quite regularly, about every three days, but sometimes even more 
frequently, I get crashes with Rev.3.5.. Stack and IDE vanish at once 
and completely, in rare cases I get a warning from the Windows system 
that the Rev.exe file has problem (when working on my Mac, I get the 
same kind of crashes). I have had the case of one more corrupted stack, 
which however was intact  in so far as I could retrieve the scripts from 
the stack with a word processor (In another such case I had reported 
earlier a substantial part of the corrupted stack had even be deleted - 
and another - not corrupted - stack, from which I had try to copy 
objects had been partially damaged, i.e. a number fo objects were 
missing afterwards including such element I had *not* tried to transfer).
I have not yet been able to find out the exact cause and its location in 
the scripts for these crashes. I have the feeling that somehow "toxic 
waste" is accumulating in stack and/or engine which then causes crashes 
when a certain level has been reached. It may well be related to the 
frequently applied procedures of various kinds of snapshot-taking, 
masking, setting angles, and grouping or regrouping of images.--


I hope for the next version of Rev to offer a better platform for such 
tasks, and I need such a safe basis before I go public with my Gradient 
Kaleidoscope stack.
Another reason for the delay is that due to other predelictions and 
obligations programming with Revolution is now less at the center of my 
interests than it has been before.


Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Highlight instances of found text

[Wilhelm Sanke]

On Wed Jul 8, 2009, Sivakatirswami katir at hindu.org wrote:




Aloha and Namaste, Peter

Thank you!  this is very helpful... it's what I was looking for, but my
string manipulation skills are not as strong as yours and I defaulted to
the old "hack" which is to use find and then FoundChunk, which always
*seems* to work well, but often introduces some unsolvable gremlin.  
e.g. my function passes all lines/Paragraphs containing the search

string to a field for review, highlighting every instance of the found
text. The user can then print this out after editing it.

Using "Supreme Being" it found all the instances, but for some
mysterious reason highlighted all instances except

"Supreme Being;

(snip)



It may be additionally worthwhile to have a look at the scripts of my  
"Hypertext Annotations" stack (2004), where searched strings are 
highlighted irrespective of other leading or trailing characters.


<http://www.sanke.org/Software/HypertextAnnotations.zip>

Regards,

Wilhelm Sanke

<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev cannot open my jpeg ? - but it is possible!!

[Wilhelm Sanke]

Jim Sims sims at ezpzapps.com had written on
Sun Jun 28,2009:

 

On Jun 28, 2009, at 7:07 PM, Mike Markkula wrote:

> I too wish wish wish Rev would remove the 4095 pixel width limit!
> (there is no height limit) As is, its a deal breaker for any serious
> app in the photography arena.

The hindrance extends beyond the scope of photography.



I tried here (Windows XP) to import an image with a width > 5000 both to 
an image with its loclock set to true and false using the script below


on mouseUp
 answer file "Choose image file" with filter "*.jpg;*.png"
 put it into tfile
 put "binfile:" before tfile
 put URL Datei into img "x"
end mouseUp

In both cases there were no problems. If the image into which the 
imported image is being placed has its loclock set to true, the wide 
image image will just adapt to the set image width of the accepting 
image. If not then the imported image is displayed with its full size - 
and you then scroll it if you like vertically and horizontally.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Editing group mode

[Wilhelm Sanke]

On Fri Jun 5 21,2009, J. Landman Gay jacque at hyperactivesw.com wrote:

Wondering if anyone has seen this in Rev 3.5. When I go into Edit Group
mode and select an object, the property inspector doesn't see it and
doesn't change to show its properties. Right-clicking an object doesn't
bring up a contextual menu. The object can't be edited. Returning to
normal mode, I can select and work with the same objects normally. The
problem is, I need to change their layering and I can't do that from
regular mode. (I didn't try changing relayergroupedcontrols yet, because
of what happened next.)

So I opened the stack in MetaCard, and its control brower doesn't work
with the objects in edit mode either. Clicking a line in the control
browser immediately selects a different line. From the message box,
asking for any control's layer always returns 9 (there are 24 objects,
some in a couple of sub-groups.) On card 2, when editing its single
group, all 9 objects there are reported as layer 8. Setting an object's
layer directly from the message box doesn't stick; the layer doesn't
change and the incorrect layer is still reported.
--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


Tried with 3.5 and 3.0 using the Metacard IDE.

Objects in a group can be edited both with 3.0 and 3.5, but clicking on 
an object is not reflected in the Control Browser (hiliting the specific 
line of the Control Browser) with 3.5. If you ask about the layer, you 
will indeed get the same number for all objects of the group and this 
number seems to be near the total number of objects on  the card in 
question.


Regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Background image problems

[Wilhelm Sanke, FB01]

On Thu, 4 Jun 2009, "Sumner, Walt"  wrote:

> Can anyone shed some light on using paint tools and imagedata on images in a
bg group?
>
> (snip)
>
> Because the new picture might look a lot like the old picture, the script
selects some gray color and uses the pencil to draw horizontal lines over the
first picture. This is fairly quick and gives a clear impression that the
picture is being rebuilt. This works fine if the image is not part of a group.
It works if the image is not the only image in a group. It seems not to work if
the image is the only image in a group
>
> (snip)
>
> Thanks,
>
> Walt Sumner

Painting on images inside groups does not work as it should. Seems to be a bug,
which I also encountered some time ago.

A workaround would be to temporarily move the images out of the group (as I did
in one of the versions of my Imagedata Toolkit) like in this script

"on mouseUp
  set the imagedata of img x to the imagedata of img x
# cannot remember what the above line achieves
  set the relayergroupedcontrols to true
  put the layer of img x into tlayer
  set the layer of img x to top
  send "mouseup" to btn "distortions: choose shape"
# the line above now paints on img x
  set the layer of img x to tlayer
  set the relayergroupedcontrols to false
end mouseUp"

Maybe this helps?

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

-- 
Wilhelm Sanke



This mail sent through http://www.uni-kassel.de/www-mail

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Sheets at the bottom and the sides?

[Wilhelm Sanke]

On Wed May, 2009, Richmond Mathewson richmondmathewson at gmail.com wrote:



It is easy to open a substack as a sheet inside another stack.  The sheet
appears at the top of the parent stack as a drop-down dialogue box.

Is there a way to make the sheet appear at the bottom or at one of the 
sides

of the parent stack?


Check out my 6-years old stack "Drawers".

<http://www.sanke.org/Software/Drawers.zip>

Maybe you can make use of some of the ideas there; drawers can be 
started from any point of a stack and even in diagonal directions.


From the comments of side "Tools and Samples for Development" of my website

<http://www.sanke.org/MetaMedia>:

"Demonstrates the use of "drawers" without using the new "drawer" 
command introduced in Revolution 2.1.2. Therefore these forms of drawers 
can be implemented also with older versions of Metacard and Revolution 
and on any platform. Drawers can slide out and back at any point of the 
rectangle of the main stack and even in diagonal directions."



Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

How to join the Teton Range and the Alps (was: Joining 2 images)

[Wilhelm Sanke]

nfluences political proceedings in Germany to a 
substantial degree, because it makes it difficult to speak "with one 
voice" in international matters.


Before you enter a restaurant in the Teton region, you have to make sure 
that the restaurant has a license for liquors. Otherwise you might end 
up digesting your steak with biologically correct water or, what is 
worse, Coca Cola.

Mormon country is near.
But there is hope: Even in Salt Lake City, not far from the Tabernacle, 
there is (or was?) a Mexican restaurant - favoured by students of 
Brigham Young University (Devin Asay will surely know) - that serves 
spicy dishes along with alcoholic beverages.


In Berchtesgaden one of the favourite drinks is "Enzian", a liquor made 
form the roots of a blue or yellow flower with a distinctive earthen, 
but wonderful flavor.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/Metamedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[ANN]: Kaleidoscope Gallery 2 (still crashing 3.5)

[Wilhelm Sanke]

I have uploaded a new Kaleidoscope Gallery containing about 100 images to

<http://www.sanke.org/Software/KaleidoscopeGallery2.zip> (size 15 MBs).

The zipped folder contains an updated version of my "Thumbs and Slides" 
stack for convenient viewing of the images (JPEG and PNG formats)..


Start "Thumbs and Slides 09" and then first update the path to the image 
folder on your computer by using button "Select image folder".


In "thumb view" - when you have started the stack - the images are 
displayed in batches of 12 with a maximum size of 240 x 180, but resized 
to their proportions up to that size. You can step through the folder 
forwards or backwards seeing 12 images at one time.


Clicking on one of the "thumbs" displays that image in a larger format 
(one of 4 formats can be chosen), the "default" with which the stack has 
been saved is "real size x 2", because this seems to me to be an optimal 
size for viewing images whose rects do not exceed 400 x 300 pixels.
In this "slides view" you can either step through the folder forwards or 
backwards or start an endless "slide show". The speed of display can be 
be adjusted any time while the slide show is running. Clicking on the 
enlarged image in "slides view" brings you back to "thumbs view".--


After bug 7812 that had caused substantial damage in stacks (corrupting 
whole stacks or deleting a number of buttons on a card) has been fixed 
with version 3.5, no further corruption occurs now, but unexpected and 
not yet fully explained crashes and weird effects still happen when 
using my "gradientology" stack with which the kaleidoscopic images have 
been created.


Until these bugs will have been resolved in newer versions of Rev, I 
think it appropriate not to release the "gradientology" stack to the Rev 
community. At present I am getting nearer to finding the relevant 
scripts that may be involved in causing the crashes, but as the crashes 
occur only in a certain percentage of cases - sometimes in one out of 10 
cases, at other times in one of 20 cases, and sometimes just trying to 
show an otherwise hidden image will result in an immediate vanishing of 
stack and IDE without any prior error message - it is difficult to 
define the possible causes of the crashes and other weird effects.


The "Thumbs and Slides 09" stack, however, is clean.

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[ANN]: Kaleidoscope Gallery (and a corrupted stack)

[Wilhelm Sanke]

I have uploaded a Kaleidoscope Gallery - about 30 images on 5 cards - to

<http://www.sanke.org/Software/KaleidoscopeGallery.zip>.

While putting the examples together using a number of differing 
techniques, the working stack suddenly became totally corrupt the day 
before yesterday, this having been preceded by rather frequent crashes 
described in bug report 7812.


After having been notified that bug # 7812 has now been fixed with Rev 
version 3.5-RC1,  I had used my stack with that new version (and 
alternatively with 3.0-gm3), and soon after having opened the stack with 
both versions the "corruption" occured. There is not even a "backup" 
stack anywhere on my harddisk, one of those preceded by a "tilde" (~), 
to which I was referred to by the Rev error dialog.


I opened the remnants of the corrupt stack with a text editor and saw 
that about 20 scripts had completely disappeared, meaning that about a 
week's work was lost. I am in the course of reconstructing the scripts, 
there are no special problems involved, but it takes some time.


Before the corruption,  apart from the crashes a number of weird things 
had happened, among them


- A simple "flip horizontal" script refused to stop (no repeat loops 
were involved here) and went on forever.


- A number of buttons in a supporting stack - one from which I wanted to 
import some relevant scripts - were being deleted, presumably because 
they were incompatible with the # 7812 problem.-


I will describe the procedures used to create the kaleidoscopic images 
in greater detail later. They will be part of my announced 
"Gradientology" stack. For the time being I mention a few general 
principles here:


- The main principle to create kaleidoscopic images is to apply mirrors, 
especially "diagonal" mirrors, but in conjunction with non-diagonal 
mirrors. There are a number of such mirrors in my "Imagedata Toolkit" 
stack (<http://www.sanke.org/Software/ImageDataToolkitPreview3.zip>)


- Another element involves using snapshots of rotated images and to 
super-impose their imagedata.


- Then modifying the imagedata by changing the colors can be an 
essential element (e.g. "duplicating colors" in my "Imagedata Toolkit" 
stack and elsewhere).


- Skewing, stretching, and resizing are other useful techniques.

A short description of the main steps in one approach:

1. I create an image that contains a number of squares with 
bi-directional gradients (again: see the "Imagedata Toolkit")


2. The image is "skewed" by a chosen factor

3. A "triangle" is chosen from anywhere in the image.

4. This triangle is positioned four times at the top, right, bottom, and 
left side of the image


5. This image created so far is rotated by an angle of 45 and 
superimposed with the original image, thus producing an octagonally 
mirrored kaleidoscope.


6. If you repeat this latter process with an angle of 22.5 you get a 
sixteenfold kaleidoscope.--


Enjoy the examples of the gallery.

IMHO I think that Revolution has a much greater potential to create 
kaleidoscopic images than an number of programs and results I found with 
Google searches on the net.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Fatal crashes with paint tools (engines 3.0 and higher)

[Wilhelm Sanke]

I had looked at an older stack developed with engine 2.6.1 (the fastest 
engine so far when it comes to image processing) where I had 
experimented using the paint tools to create color gradient shapes. My 
idea was to integrate worthwhile scripts from there into my upcoming 
"Gradientology" stack.


The report number of the bug database is 7812.

I encountered two kinds of bugs:  (see: 
<http://www.sanke.org/Software/PaintToolRev3CrashTest.zip>)


1. When an image has been resized before the rect or oval tools are 
applied (using the drag command) or the image is being resized inside 
the script creating the gradient, then Rev experiences a total crash, 
meaning it disappears at once from the screen without any prior error 
messages.  I tested this on Windows XP and MacOS 10.5 with engines 3.0 
and higher.


The remedy here is to "set the imagedata of img "x" to the imagedata of 
img "x" immediately after the resizing has taken place. This is *not* 
necessary with engine versions 2.9 and earlier.


You can test this bug by commenting out the "set the imagedata" line 
in the scripts of the three gradient buttons on the bottomleft of the 
test stack.


2. When an image has been masked and thereby changed its dimensions, 
applying the gradient-creating scripts with the rect and oval tools 
crashes Rev even with the "set the imagedata..." workaround.


You can test this by converting the test image to a beveled roundrect 
image with a shadow (button "create roundrect shadow bevel") and then 
trying to build the gradients.


This second bug also appears in engine 2.9, but not in versions 2.8 or 
2.6.1. I did not find a workaround to avoid this bug - other than, of 
course, by removing the mask before creating gradients.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [PRE-ANN]: Gradientology

[Wilhelm Sanke]

I noticed that the height of the non-scrolling card of my stack

<http://www.sanke.org/Software/GradientologyPreview.zip>

could impede the display of the presented multi-directional gradients on 
monitors with lower resolutions.


I have therefore added a webpage with the same contents for more 
convenient and quicker inspection


<http://www.sanke.org/GradientButtons.htm>

Regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[PRE-ANN]: Gradientology

[Wilhelm Sanke]

I am presently working on a stack that combines a number of 
possibilities to create gradients and gradient patterns inside Revolution.
The stack does *not* make use of the new gradient tools in Rev 3, but - 
for the most part - assembles various techniques already used in my 
"Imagedata Toolkit" stacks and elsewhere to produce gradients with and 
in images. Some of these techniques have been refined and new ones have 
been added.


<http://www.sanke.org/Software/GradientologyPreview.zip>

The preview stack just shows one card with a number of beveled buttons 
(ovals, rects, roundrects, and stars) with multi-directional gradients 
and gradient patterns.


For those who might wish to experiment with the possibilities provided 
in my "Imagedata Toolkit" stack - spread and hidden there among the 
several hundred functions - here is the URL of this stack again:


<http://www.sanke.org/Software/ImagedataToolkitPreview3.zip>

One limitation of this old stack is that you can work only with images 
of a size of  640x480, whereas the upcoming Gradientology stack will 
allow any image size and immediate resizing.--



Mark: "Gradientology" is the science of not un-intelligent 
(r)evolutionary design.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polygon Games

[Wilhelm Sanke]

On Wed Feb 25, 2009, Richmond Mathewson geradamas at yahoo.com wrote:


Anybody coming up with an answer as to how to export the polygons
surrounded by transparency would win my undying gratitude.

sincerely, Richmond Mathewson.




Richmond,

Take a look at the various examples of  stack 
<http://www.sanke.org/Software/SnapshotTestStack.zip>.


To get the transparency of a graphic you could use:

"export snapshot from rect(rect of grc "polygon") of grc "polygon" to 
img "placeholder" as PNG"


and - if necessary - when you want to include other properties of the 
polygon area like gradients or text on the polygon, then take another 
snapshot with the syntax


"export snapshot from rect(rect of grc "polygon") of this card to img 
"placeholder2" as PNG"


and set the alphadata of img "placeholder2" to the alphadata of img 
"placeholder".


Best regards,

Wilhelm Sanke


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [ANN]: "Word Match" (language tool + dynamic labels on icon images)

[Wilhelm Sanke]

I had written:

Joe Lewis Wilkins pepetoo at cox.net wrote (Tue Feb 17, 2009):

Hi Wilhelm,

In the stack Spanish to English, it appears that the lists you're  
using are out of sync by one. Maybe something I did, but I don't 
think  so.


Otherwise, great job.

Joe Wilkins


Hi Joe,

Did you change anything in the hidden Spanish field? It is crucial 
that commas, slashes, and CRs are at their correct places - and that 
there is no extra CR at the bottom of the field (creating a blank line).


I see nothing here that would be out of sync.

Maybe you should download the stack again. In any case, let me know 
when anything is not working properly.


Joe,

It came to my mind that one of the peculiarities of the Rev IDE could 
cause a minor problem when the stack is being opened (I usually use the 
Metacard IDE for about 90% of my development):


If you first press button "Repeat" after the stack was opened - which 
should enable you to "repeat" the exercise with the same word pairs 
chosen before - then the global variable "gSelection" that stores the 
temporary word pairs will be empty, because the Rev IDE starts with a 
default setting to the "pointer tool". Therefore "send mouseup" to 
initialise variable gSelection in the openstack handler (contained in 
the script of the card) will not be sent.


The remedy for this is simple: I put "choose browse tool" directly 
before the "send mouseup" line in the openstack handler, and now the 
"repeat" button works even in the Rev IDE immediately after opening the 
stack.


I have placed the stack with the added scriptline at the same URL as before.

<http://www.sanke.org/Software/WordMatch.zip>

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: [ANN]: "Word Match" (language tool + dynamic labels on icon images)

[Wilhelm Sanke]

Joe Lewis Wilkins pepetoo at cox.net wrote (Tue Feb 17, 2009):



Hi Wilhelm,

In the stack Spanish to English, it appears that the lists you're  
using are out of sync by one. Maybe something I did, but I don't think  
so.


Otherwise, great job.

Joe Wilkins



Hi Joe,

Did you change anything in the hidden Spanish field? It is crucial that 
commas, slashes, and CRs are at their correct places - and that there is 
no extra CR at the bottom of the field (creating a blank line).


I see nothing here that would be out of sync.

Maybe you should download the stack again. In any case, let me know when 
anything is not working properly.


Regards,

Wilhelm
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[ANN]: "Word Match" (language tool + dynamic labels on icon images)

[Wilhelm Sanke]

The primary purpose of this stack

<http://www.sanke.org/Software/WordMatch.zip>

is to present a practical example how - as one of several options - the 
results and proposals of the discussion in the recent thread "Dynamic 
labels for buttons with (oddshaped) icon images?" could be applied.
Part of the discussion and the findings are supplied with the stack 
(button "About text on icons") as is an overview (button "help") how to 
work with the stack and how it is structured.


As a "language tool" (for second-language learning) it is a rather 
elementary example. It is an adaptation of one of the various examples 
in an older stack from 2001 that introduced students to the basics of 
educational programming. (see stack "Seminar01" on page "Tools and 
Samples for Development" of my website <http://www.sanke.org/MetaMedia>).


There are two longer word lists - "Spanish-English" and "English-German" 
- from which you can choose for the exercises.


Because of the demonstration character for "dynamic labels" the stack 
lacks a number of features one would normally expect in a more 
sophisticated educational environment, like


- import of vocabulary from external files
- subsequent selections from fld "Lexicon" until all words have been 
selected at least once, i.e. not applying random selections each time 
from the complete "Lexicon" as in the present version

- numerical feedback as to correct and wrong matches
- collecting wrong matches in a separate temporary "lexicon" as a basis 
for "loops" that can be repeatedly used - thus adapting the program to 
the individual learning progress of the user, etc.-


An example of a more pedagogically structured stack would be "Image and 
Words" (<http://www.sanke.org/Software/ImageAndWords.zip>) that shows an 
educational environment in stages of increasing complexity.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Button Basher images

[Wilhelm Sanke]

Hi Richmond,

I created a red and beveled circle (with light effects) in "RealDraw 
Pro" and replaced your circle image in stack "BB alpha" with the new image.
The images exported with your button "Export Button Images" maintain the 
original form, color, and transparency of the new (resized) circle 
image, meaning:


Your Revolution code - although somewhat redundant in places - works as 
you intended, but with one exception (as I only now have noticed, 
because I had not looked at the inverse image before): The inverse 
version of the exported image is identical with the normal version, no 
"inverse" effect is to be seen. This also holds for the two exported 
images when one uses your own white template images.


You will have to look into the matter how to achieve an inverse effect. 
I am presently experimenting here to achieve a satisfactory result.


Setting the ink of img "holder" to "notScrCopy" produces a nice inverse 
image. The problem seems to be the export of the image along with the 
new ink to an external file, and this indeed could be related to the 
specific "volatile" nature of PNG-images just having been created in 
Revolution.
I need to have a look at the scripts in my "SnapshotTests" stack for a 
possible solution.


Regards,

Wilhelm Sanke




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Button Basher

[Wilhelm Sanke]

Richmond Mathewson geradamas at yahoo.com wrote:


Wilhelm Sanke wrote:


"I see you have achieved the functionality you intended"



which is very kind, but not true:

The first shape that is loaded will produce a PNG image surrounded by
transparency IFF it is not resized; subsequent images are all bordered
with white. Obviously resizing an image damages its alphaData.

sincerely, Richmond Mathewson.



Richmond,

Here is what I did (WindowsXP, Rev 3.0):

- Chose the "pentagon" shape and put text on it
- resized the height
-exported to "Pentagon"
- resized the same shape again - without "reset" in between
-exported to "Pentagon2"
- now reset everything
- chose the "pentagon" shape again
- resized the shape
- exported to "PentagonAfterReset"

Result: re-Imported "Pentagon", "Pentagon2", and "PentagonAfterReset". 
All images - which have a solid white background (as have the shapes 
from which one can choose) - show the expected transparency, i.e. not 
only a white border.


Is it possible that your shapes originally had a different color than white?

In any case, if you have problems here, they indeed could be related to 
the effects I had described in my last post and to the special 
Revolution image format that I had named to be "pre-PNG".


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Button Basher

[Wilhelm Sanke]

On Wed Feb 11, 2009, Richmond Mathewson geradamas at yahoo.com wrote:



I have found the nature of the earlier problem I wrote about:

When a template image is chosen for an odd-shaped button, unless the
card is exited and returned to, the alpha-data from that image is not 
recognised.


And, if you understand what that means and why it happens you are
a better person than me :)

However, this has meant that I got BADLY DISTRACTED for about 3 days
remaking PNG images in GIMP - when the whole problem resided with
Runtime Revolution; Generalised Gnashing of Teeth!

sincerely, Richmond Mathewson.



Richmond,

I have come across similar or even the same problems. I quote here a 
part from the text of the "discussion" on card "Prefabricated Masks" of 
my sample stacks "MoreAboutMasks" and "MoreAboutMasksRev3":


"A final observation concerning the creation of masks inside 
Revolution and using the "import snapshot" format:


If the resulting mask image is not first saved as an external file and 
then imported again, meaning if it remains as freshly created inside a 
stack or was just copied from another mask-producing stack, then this 
mask image will have a different quality, which we might call a "pre-PNG".


Pre-PNGs behave somewhat differently than normal PNGs: You cannot 
transfer its alphamask to the image-to-be-masked when the pre-PNG is 
hidden, at least not several times with resizing. After you have 
resized a pre-PNG during the masking process, you might find that it 
is suddenly "empty", but it can be restored when you copy and paste it 
(it then appears in its original size and shape).
A workaround to overcome this problem is to store the mask in a custom 
property of its own and then to "initialize" the mask each time before 
it is used in the calling script:


"put the CPimg of img "transition" into img "transition""

But of course you can easily convert a pre-PNG to a full PNG by saving 
the image as an external file."--


===
The new "shapes" card of your "BB alpha" stack seems to work without 
problems here (Windows XP and Rev 3.0). I see you have achieved the 
functionality you intended, and you could apparently make some use of 
the support offered in the discussion on this empathic list.


Once you haved reached this stage of development, you could now proceed 
to fine-tune your scripts. There seems to be some room to weed out 
redundancies.
I had a look at the script of button "EXPORT BUTTON IMAGES" with its 
about 40 lines of script. You could reduce that script to only 20 lines 
without influencing or changing the any of results when running the script.


If you are interested in details, I could contact you off-list, but 
anyhow your script - as it is - provides the functionality you have 
intended.


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dynamic labels for buttons with (oddshaped) icon images?

[Wilhelm Sanke]

After some further contemplation it occurs to me that we really do not 
need complex scripts (considering textsize, textheight, image height, 
button height in various combinations) to set a label on top of an icon, 
but that we can achieve most of the necessary adjustments manually with 
the possible exception perhaps of a scrollbar script like this:


on scrollbarDrag x
 put x into tTopMargin
 put x into tBottomMargin
 set the margins of btn "x" to 0,tTopMargin,0,tBottomMargin
end scrollbarDrag

Recommended steps of a mostly "manual" procedure:

- set the showname of the button to false
- assign an icon to the button
- adjust the button size so that the icon image is fully displayed
- set the showname of the button to true
(the height of the button will be increased automatically with this step)
- now use the scrollbar to adjust the position of the label / name
- then group the button
- finally adjust the rect of the group manually to show only the icon 
part of the button


The grouped icon button can than be copied and pasted as often as is 
needed in a given application.


You now have a number of icon buttons whose labels can be changed at 
runtime.-


(After you have solved a chess problem, you often have the feeling that 
the solution really was obvious in the first place.)


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dynamic labels for buttons with (oddshaped) icon images?

[Wilhelm Sanke]

In my last post of this thread I had proposed the following script 
(based on the original proposals of Jacqueline and Klaus) to position 
the label of a button with an icon image:



"on mouseUp
 put the icon of btn 12 into tID
 put the height of img ID tID into timgheight
 set the height of btn 12 to (timgheight  + the textheight of btn 12)
 put the height of btn 12 into tBtHeight
# the line above to simplify the following computations
 put (2* (tBtHeight-(the textheight of btn 12 + the effective textsize 
of btn 12))) / tBtHeight into tDivFactor
 put (the height of btn 12 - the textheight of btn 12 - the effective 
textsize of btn 12) / tdivfactor into tMargin

 set the margins of btn 12 to 0,tMargin,0,tMargin
end mouseUp" 
(Pay attention to possible line breaks in the mail). 

and added:

The script above (most accurately) places the label "on top" of the 
icon with any icon image height and fontsize. What we might still need 
is an extra tiny "jiggle" factor that achieves another mini-adjustment 
of 1 to 3 pixels.
Having arrived at that level of insight it was quite natural to conclude 
that we could fine-tune the position of the label with a scrollbar that 
adjusts the relevant margin items by increments of 1. This works fine 
here; I will add the scrollbar (and other enhancements) to the next 
version of sample stack "DynamicImageButtons".


I have also tried to automate the setting of the group rect to the 
height and width of the icon image and then to set the topleft of the 
group rect to the topleft of the button. You have to make certain 
adjustments here that take into account that the height of a group is 
greater than the original height of the control that was grouped by 8 
pixels.
I did not yet find out out how to exactly synchronize the toplefts of 
button and group, and I remember that there are generally problems when 
you try to adjust the position of controls inside a group by script.


But of course - other than the problem of adjusting the label position - 
it is quite easy to adjust the group rect manually to the size of the 
icon image.


Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Dynamic labels for buttons with (oddshaped) icon images?

[Wilhelm Sanke]

Returning home from my extended weekend I looked at the results of your 
lively discussion.


I support Klaus'  enhancement request 3265, which is indeed exactly what 
I had in mind.


I also experimented with the "jiggling" approach and found the following 
enhancement (at least I hope it is an enhancement),


- calculating the necessary total new height of the button rect, and
- computing the DivFactor, which varies among other factors according to 
the textsize:


"on mouseUp
 put the icon of btn 12 into tID
 put the height of img ID tID into timgheight
 set the height of btn 12 to (timgheight  + the textheight of btn 12)
 put the height of btn 12 into tBtHeight
# the line above to simplify the following computations
 put (2* (tBtHeight-(the textheight of btn 12 + the effective textsize 
of btn 12))) / tBtHeight into tDivFactor
 put (the height of btn 12 - the textheight of btn 12 - the effective 
textsize of btn 12) / tdivfactor into tMargin

 set the margins of btn 12 to 0,tMargin,0,tMargin
end mouseUp"

(Pay attention to possible line breaks in the mail).

I have replaced the *div* operator of Jacqueline's and Klaus' scripts 
with the simple division using "/" as it provides finer adjustments.
(Revolution in many cases handles fractional values excellently and many 
scripts - especially such with longer repeat loops - can be speeded up 
enormously  when we leave out "trunc", "round" etc. You can, for 
instance, see this when changing color values of imagedata with "numtochar")


The script above (most accurately) places the label "on top" of the icon 
with any icon image height and fontsize. What we might still need is an 
extra tiny "jiggle" factor that achieves another mini-adjustment of 1 to 
3 pixels.


The resulting button is higher (with the transparent area at the bottom) 
than the icon image, which for some uses may need extra workarounds, 
e.g. if you want to drag the button to a field and set the loc of the 
button to the loc of the field (using "intersect" etc.).


But what you can do now is to *group" the button and set the height of 
the group to the height of the icon image.


=
Scott Rossi had written:


It's possible, but it's not a little script. :-)  I demoed a customizable
button object at the last RevLive conference in Vegas.  One can set 
the font

of the text, the orientation of the text, margins, and include an icon
(which orients itself as expected, as opposed to the current 
behavior). But
this all needs to be handled as a group of objects. Features in the 
upcoming

version of Rev will make this type of control much more practical for end
users.


So your not-so-little-script probably contains more and other factors to 
achieve a perfect adjustment.


I suppose you refer to the scripts of "tm|button" of your "tm|elements", 
which however have not yet been released - at least I could not find a 
relevant link on your homepage. Will your "tm|elements" be released any 
time soon?


Best regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Transparent

[Wilhelm Sanke]

Transparent
Richmond Mathewson geradamas at yahoo.com wrote:


Working from your advice I wrote the following script:

on mouseUp
  put top of group "gX" into TOPP
  put bottom of group "gX"  into BUM
  put left of group "gX"  into LEFTT
  put right of group "gX"  into RITE
   put LEFTT & "," & TOPP & "," & RITE & "," & BUM into fld "fRECT"
  put fld "fRECT" into FRECT
  put the windowID of this stack into WINDY
  set the fileType to empty
 export snapshot from rect FRECT of window WINDY to img "HOLDER" 
as PNG

 set the alphaData of img "HOLDER" to the alphaData of img "TRANS"
 export img "HOLDER" to file "GOTTIT.png" as PNG
end mouseUp

where the group "gX" contains an odd-shaped image and a transparent
button.

Everything works well until:

 set the alphaData of img "HOLDER" to the alphaData of img "TRANS"

which makes ALL of the image "HOLDER" transparent!


If you group a field or another object its dimensions are different from 
the rect of the original field. However, to apply imagedata or alphadata 
from one object to the other both objects must possess exactly the same 
dimensions.


What does "transparent button" mean in your case? "opaque" set to false?

I thought your aim was

- to place text on an image
- and then later to integrate this text image as an icon in a button.

This could be achieved by placing a graphic or field with text over the 
image.
The rect of the graphic or field must be equal or smaller than that of 
the image and it must be inside the rect of the image.

There is no need to group graphic and image at this point.

Then you can use

"export snapshot from rect(the rect of img "trans") of this card to img 
"placeholder" as PNG

set the alphadata of img "Placeholder" to the alphadata of img "trans""

Only these two short lines are needed.



I have to start to pack my luggage now.

Best regards,

Wilhelm Sanke
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Dynamic labels for buttons with (oddshaped) icon images?

[Wilhelm Sanke]

Both Chipp's "ButtonGadget" and Richmond's "Button Basher" automate the 
process of glueing together images with text - and other properties - 
and finally produce buttons with 2 or 4 icon states.


Chipp's application possesses a number of nice and useful features, 
which otherwise you may find only in other commercial or open-source 
Photo tools. Richmond will probably develop his stack in a similar 
direction. It is good to know that there are quite a number of 
possibilities inside Revolution.


Of course one could also use low-priced or free photo tools for such 
tasks, like "RealDraw Pro" (which I use a lot), "PaintShopPro", or "Gimp".


The result of all these approaches are buttons or images with "static" 
text, i.e. text that needs not and cannot be changed - with the 
exception that you could produce different texts, colors etc. for the 
different icon states.


This is probably sufficient for the majority of applications in which 
buttons are being used.


However, in some cases, especially for certain types of educational 
software, you need the feature to be able to *dynamically* change the 
text/label of buttons at runtime.
As an example, imagine a Matching Exercise for second-language learning 
where you have got two columns of 10 buttons each - one columns of 
buttons with words of the first language, the other column for the 
second language - in which you have to drag the matching button near to 
the foreign language equivalent.
Then after all pairs have been correctly matched, a new set of 10x2 
words or expressions are being displayed in the labels of the 20 buttons 
etc. etc.


We use quite a variety of such exercises for the students studying in 
our Language Department that rely on assigning new labels dynamically 
from an attached database or a hidden vocabulary field inside the stack 
itself.


If you just use normal buttons - without icon images - there is of 
course no problem to achieve such dynamic setting of labels, but if you 
choose to be creative with presumeably more appealing buttons with icon 
images and transparent shapes then you run into difficulties:


- The name or label of a button can be displayed on the right or the 
left side of an icon or *beneath* the icon, but not directly *on top* of 
an icon. If the latter would be the case, this would be very convenient 
for dynamic label setting.
About 10 years ago - or maybe even earlier - I had asked Scott Raney to 
introduce such a feature for Metacard, but apparently it was of limited 
priority on his agenda.


- The other possibility to place text directly over icon images is to 
set an icon as a backpattern of the button. This works fine as long as 
the icons are rectangular, when they are oddshaped, however, the 
transparent parts of the image show as black.
I assume that this basically could be changed in a future version of 
Revolution so that the transparent parts of backpattern really would 
remain as transparent.


Lacking such features at present, one workaround would be to take a 
labelles/nameless button with several icon states and to combine the 
button with a graphic/field, grouped together with the button or just as 
an overlay to the button. This is one way to achieve dynamic setting of 
labels at runtime.-


I have put together a very small stack that just shows four different 
icon images and four dynamic button entities which replaceable text; 
this is not an educational exercise, just demonstrating in which ways 
buttons and graphics could be combined.


<http://www.sanke.org/Software/DynamicImageButtons.zip>

(I will be out of home and office for the next three days.)

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Transparent

[Wilhelm Sanke]

On Wed Feb 4, 2009, Richmond Mathewson geradamas at yahoo.com wrote:
   

I made an image via IMPORT SNAPSHOT on a card, set its INK to
TRANSPARENT:

But when I exported the image as both PNG and GIF the transparency
was lost.

Does this mean that transparency is only local?

sincerely, Richmond Mathewson.


I assume you try to get the transparency of an odd-shaped image for use 
with your Button Basher stack?


If that is the case, then follow these steps and use these syntax examples.

1. Using "export snapshot"

  First, create an empty (and possibly invisible) image named 
"placeholder" or similar (Bernd used that name in one of his scripts).


  The odd-shaped image - transparent in the rect outside the odd shape 
- is image "trans".


  The syntax is now:
 "export snapshot from rect (rect of img "trans") of img 
"trans" to img "Placeholder" as PNG"


This captures the odd shape along with the transparency, but leaves out 
all things - transparent fields or graphics for text - you may have 
piled onto the image in Button Basher.


If you want to capture the oddshaped image with its transparency and 
together with the overlayed fields or graphics you need to apply two steps:


- "export snapshot from rect (rect of img 1) of this card to img 
"Placeholder" as PNG"


This captures the rect of the oddshaped image along with the text of 
graphic or fields, but *not* the transparency.


You then apply the transparency of the underlying oddshaped image to the 
snapshot in a second step:


- "set the alphadata of img "placeholder" to the alphadata of img "trans"

That's it.

2. Using "import sapshot".

The procedure is only slightly different.

- "import snapshot from rect (rect of img "trans") of img "trans" as 
above imports only the image without overlayed text, but with its 
transparency.


The two steps to get both:

- "import snapshot from rect (rect of img "trans") of this cd
 set the alphadata of last img to the alphadata of img "trans""

After that you could rename the 'last image'.

Is this what you were looking for?

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Odd-shaped buttons . . .

[Wilhelm Sanke]

On Wed Feb 4, 2009, Richmond Mathewson geradamas at yahoo.com wrote:


J. Landman Gay wrote:


"Just draw the shape you want with it."


Um, I've never been a great fan of the graphic tools contained within
Runtime Revolution.


It is really not too difficult to use the polygon tool to place 
irregular graphics on maps or images. See my vintage stack from 2004


<http://www.sanke.org/Software/ImageAndWords.zip>

produced for the most parts by students in a Metacard-workshop.


 However, Button Basher
relies on EXPORT SNAPSHOT which has two disadvantages:

1. A snapshot is always rectangular.

2. It never contains transparent areas.


Richmond, this simply is not the case. There are possibilities to 
produce snapshots with transparent areas. Several members of this list 
have shown that. See also the relevant examples in stack


<http://www.sanke.org/Software/MoreAboutMasksRev3.zip> and
<http://www.sanke.org/Software/SnapshotTestStack.zip>


Now I am well aware I can set up scaleable circles, ellipses
and so on: but the main problem is how to combine those with
button texts (that are also adjustable) and then export the end-result
as a GIF or PNG image.


As I see, Bernd Niggemann is presently cooperating with you in improving 
"Button Basher". He can show how you can integrate masked images (such 
with transparent areas) into Button Basher that are scalable in the same 
way as the images you use at present.


Recently I have added the feature to produce *beveled* and *framed* 
(roundrects and ovals) images that you could use in your stack and 
elsewhere, but I have not yet put together a sample stack for that.


Best regards and support for your work,

Wilhelm Sanke

<http://www.sanke.org/MetaMedia>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Drawing a curved shape - 2nd attempt

[Wilhelm Sanke]

*René Micout rmicout at online.fr  wrote:

*/
/



Hello Jim
http://home.infostations.net/jhurley/BezierLine.rev = error !?
René from Paris


Some months ago I had encountered similar difficulties when trying to access 
Jim's website via DSL,
but it worked for me using an ISDN modem.

Regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Snapshot stack (was: Import from rect)

[Wilhelm Sanke, FB01]

On Sat Jan 24, 2009, Thomas McGrath III mcgrath3 at mac.com wrote:

> This is a good observation and study of the inner workings of  
> snapshots. There are many variations in effects that can be  
> accomplished here. I especially like the explanation of what I was  
> troubled with at first that the first rect in parens is the size and  
> the second is the location. I think the global location can use a bit  
> more explanation. I will be playing with this for a bit.


Tom,

Thank you for the feedback.

I have added four commented lines to the script of btn "Globalloc..." that shed
some light on the procedure to convert rect values to global coordinates. 
It is interesting that using *globalloc()* to determine snapshots is so much
faster - about five times as I have reported - than using "import snapshot from
the rect(the rect of grc 1) of this card". For applications or tools where speed
is an issue and where snapshots are used repeatedly the globalloc variant should
be helpful.

I have also added the text of my last post as a basic information to the stack,
and already have uploaded the newer version under the same URL as before.

Regards,

-- 
Wilhelm Sanke



This mail sent through http://www.uni-kassel.de/www-mail

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Snapshot stack (was: Import from rect)

[Wilhelm Sanke, FB01]

For the few who might be interested in such things I have put together a stack
demonstrating various ways of producing and using snapshots, thereby following
the questions and findings in the recent thread "Import from rect" (especially
of Thomas McGrath, Ken Ray, and Scott Rossi):

<http://www.sanke.org/Software/SnapshotTestStack.zip>

The Rev docs about "snapshots" have become increasingly detailed over time, but
they do not - understandably - cover every aspect, and - they still contain an
old error, namely concerning the paintcompression format of imported snapshots.

The teststack allows to set the properties of the selection graphic - with the
help of which snapshots are taken from an underlying image - in "real time",
i.e. you can set blendlevel, fillcolor, and the ink directly and watch the
changes in the appearance of the area of the graphic and the image beneath it.

20 different ways related to snapshot taking are demonstrated (with almost no
commentaries), concerning "simple" snapshots, alphadata, maskdata, and
extracting blendlevel and inks.

Additional remarks to some of the aspects:

- I found it confusing at first when I encountered a syntax like "import/export
snapshot of rect(the rect of grc 1) of grc 1". Experimenting with this I
understood that this twofold reference is not just tautological, but determines
different components of the snapshot. The first term - in the brackets -
determines the *dimensions* of the rect, the second states - as it were - the
location of the snapshot.

- In all cases but one - what you see in the test stack is not  the "snapshot
taken", but the result of using the snapshot for masking the image underlying
the selection graphic.

- The exception to this is the "Darkshot" - listed by Ken Ray in his systematic
overview - where I additionally display the actual snapshot (in a diminished
size) to show that the color of the represented transparent areas is dependant
(but not identical with) on the ink and fillcolor of the selection graphic.

- Using *globalloc* to determine the rect and loc of the snapshot is about 5
times faster than using card, window, image etc. as the reference to the
location, as in "import snapshot from the rect() of this card"

- The syntax "import/export snapshot from rect( of this stack" or "of
stack " is not possible. You have to get the windowID of the stack
first and then write "snapshot from rect(trect) of window twindowID".
But it is possible to use "card x of stack " and even - see the docs
- access hidden or closed stacks this way.

- Snapshots taken from the selection graphic contain both alphadata and
maskdata, that can be used to mask the underlying image.
Compared to alphadata using maskdata produces somewhat rough edges.

- Other than when applying alphadata to the image "to-be-masked", with maskdata
you need to crop the image "to-be-masked" to the rect of the *group* that
contains the selection graphic. The graphic and the group containing the graphic
have different dimensions. When you group a graphic, width and height of the
group are greater than those of the graphic.
"export snapshot from rect(the rect of grc 1) of group 1" combined with cropping
the "image-to be-masked" to the rect of the graphic results in a distorted
rectangle - instead of an oval. Cropping the "image-to be-masked" to the group
produces the correct result.

Regards,

-- 
Wilhelm Sanke



This mail sent through http://www.uni-kassel.de/www-mail

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Import from rect

[Wilhelm Sanke, FB01]

On Fri, 16 Jan 2009, Scott Rossi  wrote:

> Recently, Thomas McGrath III wrote:
>
> >> Actually a snapshot of an object does not take an exact snapshot
> >> following the attributes of the object (transparency, etc.) but a
> >> snapshot of the rect of the object will follow the attributes
> >> (transparency, etc.)
>
> This is an excellent and useful observation -- I always thought that one had
> to group objects to get their alpha included in a screenshot, but using the
> object's rect as you say produces the same result.  Nice find.
>
> Regards,
>
> Scott Rossi


One of the steps of development in science as in programming is that we start on
a preliminary level with assumptions or hypotheses which may be then falsified -
or sometimes verified - when we reach the next intermediate level of our theory.
The principle of "falsification" is the core element of Sir Karl Popper's theory
of science.
This usually happens to all of us from time to time, although the programming
language we use is called "Revolution".

In my long post of Nov 29, 2008 ("More about Masks (+ sample stack)")
introducing stack "More about Masks" one paragraph reads:

"Scott's assumptions - expressed in the comments of his script - that the image
"to-be-masked" must be in PNG-format and the selection graphic (from which the
snapshot for the mask is being taken) must be grouped, could not be verified
here."

The stack compares and discusses in detail the attempts of Jim Hurley, Bernd
Niggemann, and of myself to create masked images mainly with the use of
snapshots - and included one script originally written by Scott to which the
paragraph refers. -

===
and  Thomas McGrath III  wrote on Sat, 17 Jan 2009:

> Scott,
>
> Actually at first I thought this was a bug, but it makes a bit of  
> sense. The rect and I guess grouping the objects will force a visible  
> or visual snapshot of where the object physically resides including  
> objects beneath that show through the alpha mask but using the actual  
> object must allow the engine to reference the object itself  
> programatically so it is not 'seeing' the alpha or better yet it is  
> not seeing through the alpha to the objects underneath.
>
> As Richard said " "export snapshot" which allows you to specify the  
> object rather than merely its rect:" "This will cause the object  
> specified to be rendered into an offscreen buffer directly, then that  
> buffer is compressed into the specified format for writing to disk."
>
> It must be the ability to render offscreen in the buffer that is the  
> difference here. This must be the case with the import snapshot as well.
>
> Tom


I think Tom's interpretation of what is going on is an excellent analysis.
Getting the alphadata is indeed possible both with "import" and "export
snapshot" and besides the alphadata you also retrieve the maskdata as we have
discussed and shown in detail in our above-mentioned stack of Nov 2008

<http://www.sanke.org/Software/MoreAboutMasks.zip>

along with the possible dependency on the paintcompression format, which however
effects only maskdata.

A new version of the stack - released a few days ago on Jan 7 -

<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>

additionally demonstrates two attempts to integrate the new "gradient tools" of
Rev (therefore this stack needs at least engine version 3) as a component for
creating masked images - based on a proposal from Bernd Niggemann..
I mention this stack here, too, because I see from the text of Tom's posts in
this thread that he is apparently experimenting with using snapshots together
with gradient tools. It could be interesting to have a look at these approaches,
although they may be of a somewhat "ideosyncratic" nature.

Regards,

Wilhelm Sanke



This mail sent through http://www.uni-kassel.de/www-mail

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution