PDA

View Full Version : Sencha Architect crashes when project is reopened (corrupted project source?)



akopov
17 Oct 2012, 4:08 AM
Sencha Architect won't open the project I have successfully working on yesterday. Until I closed SA everything was fine - no errors neither in SA nor in deployed JS generated. Then when I reopened the project next day, SA started to crash with an "unknown error":

39426

Removing Sencha folder under my AppData\Local and reinstallation of SA don't help. Other projects (including earlier versions of that one) open fine. New projects can be also created and saved, only happens with particular project.

I'd say project source is corrupted (also I see no obvious errors in its JSONs myself), but no project files have been modified outside of SA, the development has been done entirely in SA. If they were corrupted, that was probably done by SA itself.

OS version: Windows 7 64bit
Sencha Architect version: 2.1.0.000640.

The problematic project archive is attached. 39427 (the problem is the same for the archive and for the imported project).

Thanks in advance and please feel free to ask for details if needed.

akopov
17 Oct 2012, 7:05 AM
Noticed a couple of irregularities in project files, e.g. xds profject file and Application and Explorer metadata files were listing 'Folder' model which was actually renamed to TreeNode (for some reason renaming has been reflected while code worked fine in browser before I closed SA).

Editing that out didn't have any effect though.

Phil.Strong
17 Oct 2012, 8:15 AM
I've reproduced the crash on Win7. Looking into it

akopov
17 Oct 2012, 8:16 AM
Found the problem!

One of my stores I have converted from XML store into JSON store was still had {"type": "xmlstore"} in its metadata file while other properties were changed to JSON store one. So store type and properties didn't tally and project was crashing when opened.

There were other issues I've found with renamed entities, but only that one was fatal.

It looks like a HUGE problem to me :( Edits seem to be fine while the project is in memory and your application works properly, then you save the project and not all the edits you've done are actually stored.

akopov
17 Oct 2012, 8:34 AM
Having "exportPath" property set to the path that doesn't exist seems also to crash SA on load.

Makes sharing projects between different developers a bit tricky, still is a minor issue comparing to that renaming one.

Another use case which I faced last week after renaming a function, think it's relevant - function's old and new body were both appearing with old body actually preferred during deployment.

39435

akopov
17 Oct 2012, 8:45 AM
Sorry for spamming, but I have just open manually fixed project, saved it and closed.

It won't open again this time, perhaps again self-inflicted damages, this is ridiculous :(

Phil.Strong
17 Oct 2012, 11:05 AM
Ok I've isolated it. The issue is very strange and is related to

MyViewport -> MyContainer -> ExplorerTreePanel
it has rootVisible set to false and is attached to a store in the project that doesn't load any data.

Why is it doing this ....? No idea as of yet.

The fix
open /metadata/MyViewport in your fav text editor
search for "itemId": "ExplorerTreePanel"
find "rootVisible": false just below it and remove it.

It might be that when you full vet your TreeNodesStore to have a data endpoint that this will no longer occur and you can again set rootVisible false

Hope this helps.

akopov
17 Oct 2012, 11:19 AM
Thanks for your reply

I'm only starting with the product so my code is probably not following best practices. Empty store is there to access it later in runtime and populate it dynamically. It'd be better probably to create the store dynamically as well for that purpose, but that's easier for me at the moment.

I still consider that a bug because I believe it shouldn't be possible to make fatal changes to the project using the system itself and even not writing any code.

Also while looking through project source JSONs I discovered many other cases when renamed / transformed entities retained part of their properties from the previous version and part from the proper one (some of them I have posted above).

Sorry for my tone in the messages above, but that looked extremely strange to me. Is there an explanation by any chance or that is a system issue?

Thanks again for your help.

Phil.Strong
19 Oct 2012, 6:12 AM
Oh no it's most certainly a bug. A Windows only bug that exists in QtWebKit which afaik we aren't patching anymore. We're moving to another platform as soon as it's feasible (it's under way now).

akopov
19 Oct 2012, 6:26 AM
Thanks again for your help, and sorry for some ranting above, I was just extremely frustrated. Now when I know what to look for when I happens again it doesn't look that critical.

jasonehle
23 Oct 2012, 9:57 AM
Is there a way to provide "user settings" outside of the XDS?

Our team is evaluating using Sencha for our platform going forward, and we work accross a variety of configurations.

Currently it appears that when a dev updates the XDS from source control, we must everytime go in and alter the exportpath. This is a pain.

You should be able to provide a pointer in the XDS project file to a local config that overrides the settings in the XDS. The local config wouldn't get checked in and thus overwritten by the last guy who changed the path and committed to source control.

Maybe I'm missing something obvious... hope so... please let me know how we're supposed to use this in a team environment. I've read the "Collaboration" information that I could find, but it doesn't mention anything at this level.

Other than that - Architect2 is an incredible piece of software. I hope it will work out for us. I can see myself spending many years in this IDE

Regards,
Jason

aconran
23 Oct 2012, 10:03 AM
User settings are written to a file called .architect (and typically excluded from source control).

The export path is currently a project level setting. We can look into migrating it to a user level setting and/or allow the user level setting to override it.

jasonehle
23 Oct 2012, 10:49 AM
We can coordinate the paths on our end for now at least where the OSs are the same. Its a few seconds every time after updating - not super critical - but it would be great to consider it for the .architect file. Thank you for the quick reply

dotsimple
7 Dec 2014, 6:06 PM
We can coordinate the paths on our end for now at least where the OSs are the same. Its a few seconds every time after updating - not super critical - but it would be great to consider it for the .architect file. Thank you for the quick reply

I may have found a way to sort out export path issues between colaborative teams working on different systems. Do the following:

Create a project. Save it, export it (with your own path to your deployment area). Then if you are using svn or git or whatever, push it as is to the server where the team can pull it to their own systems.

The team member has to do the following: Pull the project, go inside the project folder, copy the xds file, rename it to his/her own name (for example: joesoap.xds). Edit that file in a notepad and change the name property to "joesoap" (in this case). You can choose to edit the exportPath property here, or using the sencha architect.

The idea is that Joe Soap will use the joesoap.xds file to work on the architect, and the others can use their own files. Ultimately if you add a component when using joesoap.xds, it will reflect into the other files as well. So you CAN push and pull using some sort of versioning! The only issue I have is merging issue, but I am sure git, svn or other versioning solution can assit there..!

I hope this helped...