On 7/25/13 10:50 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>Cool, this is new to me. The source-path route sound like the
>"easiest" to adopt (for anyone, not just noobs like me ;-)). Are there
>any drawbacks?
Compile time will take longer as it is re-compiling each of the source
files in the source-path instead of reading ABC from the pre-compiled SWC.
But for me it isn't that noticeable.
I've hit other occasional compiler issues where it can't resolve some
class constants that are used as optional parameters in method signatures.
I think I've generally gotten around them, but I honestly don't remember
how.
I think there are some changes that can't be made this way. Maybe change
to CSS and properties, or maybe metadata. I honestly don't remember the
details here either. But 99% of the time this is how I code. In fact,
I'm working out that resource module issue this way.
>Also, does this mean that you don't even have to build
>and decorate the SDK, but can work straight off the code you get from
>git?
Yes. At least for me, because I build from the command-line when working
in this configuration. I don't know if FB will cache anything and get in
your way. But because I can skip building SWCs I believe it saves me more
time even if each compile is slower.
I still go back to full builds when I need to use FB for things like
profiling. But because I use FDB to debug because it is usually more
efficient, I generally only use FB for code editing.
>
>EdB
>
>
>
>On Thu, Jul 25, 2013 at 7:11 PM, OmPrakash Muppirala
><bigosma...@gmail.com> wrote:
>>>
>>> Like maybe just having folks point a source-path to their local working
>>> copies. Source-path is supposed to
>>> take precedence over anything found in the library path. It slows down
>>> compilation, of course, but also means you don't have to build the SWCs
>>> before testing your changes.
>>>
>>>
>> Well, this is exactly what I do today. I isolate the problem to a
>> particular project in the frameworks folder and add that project's src
>>as a
>> source path to my test project. There maybe dependencies and I work
>> through to add all the relevant src directories until the compile
>>errors go
>> away. This makes it much easier for me to work on the SDK code while
>> testing it without having to recompile all the swcs all the time.
>>
>> I wasnt sure what the correct/better way was.
>>
>> Thanks,
>> Om
>>
>>
>>
>>> -Alex
>>>
>>> On 7/25/13 6:16 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>>
>>> >There is a gap between how you build the SDK and how you make and test
>>> >changes to the SDK:
>>> >
>>> >(working from memory here) After you build the SDK ('ant main') you
>>> >run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
>>> >Flash Builder. You then create your test application (in which you
>>> >will reproduce the bug) to use this newly build and prepared SDK.
>>> >
>>> >Now a question to all of you: can we make an app (or extend the
>>> >Installer) so the steps to prepare a system for building the SDK are
>>> >performed automatically?
>>> >
>>> >- I think we can download and launch the installers (not sure if we
>>> >can poll for completion, though)
>>> >- we can create an env.properties with all the paths set, bypassing
>>> >the need to set system wide variables in obscure settings panes/files
>>> >- we can create a preset directory structure to hold the source files
>>> >and their dependencies (AIR SDK, playerglobal etc.)
>>> >- we can find and edit mm.cfg and create a FlashPlayerTrust file
>>> >- etc.
>>> >
>>> >Does anyone see any major obstacles that I'm overlooking?
>>> >
>>> >EdB
>>> >
>>> >
>>> >
>>> >On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean
>>><jus...@classsoftware.com>
>>> >wrote:
>>> >> Hi,
>>> >>
>>> >> I took some notes while fixing this bug.
>>> >> https://issues.apache.org/jira/browse/FLEX-33165
>>> >>
>>> >> Any feedback and questions welcome.
>>> >>
>>> >> Bug information
>>> >> Note that it's marked as "easyfix" and a RTE. Generally these sort
>>>of
>>> >>bugs don't take much to fix. Looking at the report you can see it's
>>>for
>>> >>a mobile project and Adobe Flex 4.6 so the line numbers are not
>>>going to
>>> >>match up to the current development branch. Search for the line of
>>>code
>>> >>where the error occurs, as the code may of change first look for the
>>> >>function name. You can see that the error is now on line 1581.
>>> >>
>>> >> Reproduce the Bug
>>> >> There is no sample code so you need to work out how to reproduce
>>>it, so
>>> >>create a new sample mobile project containing a horizontal spark list
>>> >>and run it. See if it can reproduce the issue using the 4.6 SDK. No
>>> >>luck. (See the JIRA issue for the code used)
>>> >>
>>> >> Try and work out how to generate the RTE. Looking at the snapElement
>>> >>method it looks like the error would only occur when scrollProperty
>>>is
>>> >>null and that could happen if both canScrollHorizontally and
>>> >>canScrollVertically are false. It's possible that this could happen
>>>when
>>> >>size changes removes the scrollbars when screen orientation changes.
>>> >>This is probably why the bug is hard to reproduce as it depends on
>>>the
>>> >>amount of content in the list and the screen size. The easy way to
>>> >>simulate this is to turn off both horizontal scrolling and vertical
>>> >>scrolling and call the mx_internal method. Modify the code to call
>>>the
>>> >>method directly with both scroll bar policy off and smapping set to
>>> >>something other than none. Bingo we have the RTE!
>>> >>
>>> >> protected function init(event:FlexEvent):void
>>> >> {
>>> >> list.scroller.mx_internal::snapElement(10, false);
>>> >> }
>>> >>
>>> >> <s:List id="list" dataProvider="{listdata}" width="100%"
>>> >>height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off"
>>> >>scrollSnappingMode="center">
>>> >> <s:layout>
>>> >> <s:HorizontalLayout />
>>> >> </s:layout>
>>> >> </s:List>
>>> >>
>>> >>
>>> >> Test in the develop branch
>>> >> Change to using the latest develop branch and see if the issue still
>>> >>exists and yes it does.
>>> >>
>>> >> Fix the bug
>>> >> To fix add a null check and recompile the spark project by changing
>>>to
>>> >>the frameworks/projects/spark directory and run ant to compile, this
>>> >>should only take less than a min to compile.
>>> >>
>>> >> Clean the FB project so it picks up the framework change. Sometime
>>>it
>>> >>will cache the swc and may require swapping to and old SDK and then
>>> >>back again. Double check you are using the SDK you made the change
>>>in.
>>> >>
>>> >> Test the Change
>>> >> Run the program again and/or text code path in the debugger to see
>>>that
>>> >>the issue has been fixed. Play about with the sample application to
>>>make
>>> >>sure nothing else has been broken.
>>> >>
>>> >> Running mustella tests
>>> >> A change to the scroller class could effect a lot of tests but we
>>>can
>>> >>run the basic tests to make sure and assume the CI will pick up any
>>> >>other issues. For a change like this I wouldn't expect any issues or
>>> >>side effects as the RTE would normally occur, but it's best to be
>>>safe.
>>> >>
>>> >> ./mini_run.sh tests/gumbo/components/ScrollBar
>>> >> ./mini_run.sh tests/gumbo/components/Scroller
>>> >>
>>> >> Both sets of test pass as expected.
>>> >>
>>> >> [java] =====================================================
>>> >> [java] Passes: 122
>>> >> [java] Fails: 0
>>> >> [java] =====================================================
>>> >>
>>> >> [java] =====================================================
>>> >> [java] Passes: 74
>>> >> [java] Fails: 0
>>> >> [java] =====================================================
>>> >>
>>> >>
>>> >> Commit the change
>>> >> If you are a committer you can directly commit the change via a git
>>> >>push. If you are not not a committer you would need to generate a
>>>patch
>>> >>file and add it to the JIRA issue. Make sure you generate the patch
>>>from
>>> >>the base SDK directory like so.
>>> >>
>>> >> git diff frameworks/projects/spark/src/spark/components/Scroller.as
>>> >>
>>> >> diff --git
>>>a/frameworks/projects/spark/src/spark/components/Scroller.as
>>> >>b/frameworks/projects/spark/
>>> >> index 9f91412..c48222d 100644
>>> >> --- a/frameworks/projects/spark/src/spark/components/Scroller.as
>>> >> +++ b/frameworks/projects/spark/src/spark/components/Scroller.as
>>> >> @@ -1579,7 +1579,8 @@ public class Scroller extends
>>>SkinnableComponent
>>> >> }
>>> >> else
>>> >> {
>>> >> - viewport[scrollProperty] = snapScrollPosition;
>>> >> + if (scrollProperty)
>>> >> + viewport[scrollProperty] = snapScrollPosition;
>>> >>
>>> >> return null;
>>> >> }
>>> >>
>>> >> Update JIRA
>>> >> Mark the bug as resolved noting down the Apache Flex versions it has
>>> >>been fixed in.
>>> >>
>>> >> Hope that was helpful,
>>> >> Justin
>>> >
>>> >
>>> >
>>> >--
>>> >Ix Multimedia Software
>>> >
>>> >Jan Luykenstraat 27
>>> >3521 VB Utrecht
>>> >
>>> >T. 06-51952295
>>> >I. www.ixsoftware.nl
>>>
>>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
