

Thanks Chris, I'm glad it's running well!electrochrisso wrote:Fast, smooth and very efficient on system resources, good one Chris, cant wait to do some testing.
Thanks Zach, yes I'm using "poor man's anti-aliasing"Zach wrote:That looks nice.
I did notice on the right-edge of the expandable border, there is some visible artifacting (appears as aliasing) I'm assuming has to do with the expanding/shrinking process.. It looks fine if you find the "native" size but outside of that is pretty apparent.
I tested this out with several borders of different sizes and got great results, this will be great for creating sliding borders. With a bit of planning no one will even notice the poor man's anti-aliasing, and appreciate the smooth effect.PrincieD wrote:Thanks Chris, I'm glad it's running well!electrochrisso wrote:Fast, smooth and very efficient on system resources, good one Chris, cant wait to do some testing.
You can also try different border images by replacing the border35__.png image in the icons folder. A Google images search is a good resource of test borders but you must make sure the border image is hollow in the middle (transparent, have an alpha channel) otherwise the auto-border algorithm won't know how to chop up the image.
hehe thanks mateelectrochrisso wrote:I tested this out with several borders of different sizes and got great results, this will be great for creating sliding borders. With a bit of planning no one will even notice the poor man's anti-aliasing, and appreciate the smooth effect.
Yes that would offer flexibility, so it could be possible to animate in high frame rate, and when the animation has finished switch to low frame/still.PrincieD wrote:hehe thanks mateyes it will look better when it's animating, hmm maybe I can make it switch between high-quality for low frame-rate/still and "poor man's anti-aliasing" for high frame-rate
![]()
Chris.
Precisely!electrochrisso wrote:Yes that would offer flexibility, so it could be possible to animate in high frame rate, and when the animation has finished switch to low frame/still.
Since I can't release a dll or a tailbyte library (without breaking the user identification system), I have created a diff patch for the source version, download it here.Changelog:
- _PB 5.11 compliant : just a few fixes with the new packer system, BriefLZ is now being used.
_A new attribute for splitter gadget: #SPLITTEREX_LOCK: When the SplitterEx gadget is resized, the selected gadget will keep its size (much like PureBasic Splitter #PB_Splitter_FirstFixed and #PB_Splitter_SecondFixed ). Usage:
- SetSplitterExAttribute(ID.i,#SPLITTEREX_LOCK,#SPLITTEREX_FIRST) : When the SplitterEx gadget is resized, the first gadget will keep its size
SetSplitterExAttribute(ID.i,#SPLITTEREX_LOCK,#SPLITTEREX_SECOND): When the SplitterEx gadget is resized, the second gadget will keep its size
SetSplitterExAttribute(ID.i,#SPLITTEREX_LOCK,#Null): When the SplitterEx gadget is resized, both gadgets will be resized by ratio (default mode)
Keep in mind that min and max for each gadget are still used, so your gadget might be resized even though they are locked.
I'm also in the same situation in needing ProGUI to work with 5.11, but I ran into a problem running your patch.Poshu wrote:I'm back on Windows (once you go free you should never have to go back >.<) for a small project, I needed proGUI to work on 5.11 and I don't like DLL.
So, new unofficial version of proGUI, I hereby dub thee 1.38b!
Since I can't release a dll or a tailbyte library (without breaking the user identification system), I have created a diff patch for the source version, download it here.Changelog:
- _PB 5.11 compliant : just a few fixes with the new packer system, BriefLZ is now being used.
_A new attribute for splitter gadget: #SPLITTEREX_LOCK: When the SplitterEx gadget is resized, the selected gadget will keep its size (much like PureBasic Splitter #PB_Splitter_FirstFixed and #PB_Splitter_SecondFixed ). Usage:
- SetSplitterExAttribute(ID.i,#SPLITTEREX_LOCK,#SPLITTEREX_FIRST) : When the SplitterEx gadget is resized, the first gadget will keep its size
SetSplitterExAttribute(ID.i,#SPLITTEREX_LOCK,#SPLITTEREX_SECOND): When the SplitterEx gadget is resized, the second gadget will keep its size
SetSplitterExAttribute(ID.i,#SPLITTEREX_LOCK,#Null): When the SplitterEx gadget is resized, both gadgets will be resized by ratio (default mode)
Keep in mind that min and max for each gadget are still used, so your gadget might be resized even though they are locked.
It's quite easy to apply: put your UNMODIFIED proGUI.pb (1.38 version) in the folder, run Patch proGUI.bat, when asked, press Y and enter.
The patcher I'm using can be found here (binaries and sources): http://gnuwin32.sourceforge.net/packages/patch.htm