I have an XML layout including many times the same layout. Turns out you can't include the same layout more than 50 times without breaking the preview renderer.
Here is the error that I get:
Exception raised during rendering: Cycle found (count=51)
Would there be a way to get around this?
It works fine on device.
The guys developing Android Studio ought to set this arbitrary limit much higher really.
More like 500 maybe.
Found the code that's limiting the number of includes to 50.
Just including a different layout once works around that problem. I just duplicated the included layout for now. I think that fouls there broken cycling dependency detection somehow.
Therefore this is only an issue when including more than 50 times the same layout file without including any other layout. As long as you include another layout you still can include any one of them as many times as you want without breaking the preview renderer.
That ought to be reported to JetBrains.
Opened that issue.
Related
By default, Android Studio will detect changes to your code and apply the changes to UI while the app is running. This is great but only works for minor changes like changing color, fontsize, etc. But what I have noticed is that over time, Android Studio becomes really laggy in performance as the app grows in code size. The biggest performance hit is when the app is running in debug mode and I make changes. If I run the app but not in debug mode, it is still laggy but not as much. Typing in code gets a lot of freezes.
Is there a way to disable this automatic compiling of changes and updating the UI?
Search for Live Edit Of Literals in settings you will find an option to enable and disable Live Edit Of Literals as shown in below image
After some testing, it appears that this performance issue is related to the amount of code in the file you are editing. The file I was editing had a very large amount of code in it - 850 lines / 32k. But when I tried editing a file with significantly less code, there was no performance issues. Google needs to address this issue. A temporary fix is to break up the larger code into smaller files.
I feel like I'm going crazy, but since updating to the new version of Android Studio, I can no longer tell which files have errors in them.
Previously, if I made a change in one class, like to a method signature, then all other classes that were calling that method would suddenly be highlighted in red (at that section along the top that shows the path). Now it shows nothing as though my code is good, except when I go to compile, I now get a load of errors in the build tab at the bottom, in a really unhelpful way to navigate through.
Is this something I can switch back to through a setting somewhere? I'm really not sure what to search for, but I've been through almost all of them.
UPDATE :
Following another SO post, I turned on and off PowerSave mode, at the bottom of File menu (in Android Studio). This, temporarily at least, seems to have solved things.
This may be what you are looking for?
Either that or it may be in preferences.
I'm currently using Xamarin Studio and have a comfortable enough setup so that I can put my various pads (output, unit tests, solution tree, etc.) on different screens. I like it and I'd like it to stay the same wether I'm debugging, running tests or coding.
But right now, xamarin studio handles it himself and switches to the Debug view layout when debugging, which changes everything to their default (since I've never really changed it).
Is it possible to tell Xamarin Studio to either :
- Never switch layouts?
- Set which layout is used for each situation (and I would just use my custom layout)
I've tried deleting all layouts and XS just recreates them. No dice here.
I've tried switching to my layout when debugging, hoping it would remember "this is my debug layout now". No chance either.
And I'm hoping I won't have to change each separate layout, because first it'll take a stupid amount of time, and also because if I ever decide to make a change, i'd have to set it up over 5 different view layouts which is just ridiculous.
Note : I'm using the latest version of Xamarin of the stable channel.
So, does anyone know a way to keep one single layout for all situations?
Unfortunately, no, it is not possible with the current version of Xamarin Studio.
I read through both the preferences as well as the documentation. I even tried to create my own custom layout by navigating to "View" -> "Save Current Layout". Then I selected my new custom layout when I started a debugging session, hoping it would persist to the next one. But alas, the "Debug" view was chosen automatically.
This would probably be something you could bring forth as a suggestion of improvement to the Xamarin team. You can do so using their bugzilla.
Let me say at outset that I'm using old technology by today's standards! This happens in MFC on Visual Studio 2005 and running under WinXP. (If it 'aint broke.... ;-) )
I have a dialog based app which has a CTabCtrl with two tabs. Each contains a CListCtrl. These work perfectly under normal circumstances. They populate correctly and show and hide as they should. When I first open the application the display selection is correct. If I then minimize the dialog and restore, the CList Ctrl does not show, the tab is blank. It is the only control which has this problem. Another CListCtrl outside of the CTabCtrl does show up correctly. If I then swap tabs and back again, the other tab shows up then the first appears as normal.
This does not happen if I access any other part of the dialog before minimising, it is only when minimising is the absolute first action I take. It also happens with the CListCtrl I have in the other tab if I set this tab to be selected on startup in OnInitDialog where I set up the CTabCtrl.
I have actually solved the effect of this problem by adding into my OnSysCommand(...) the following:
if ((nID & 0xFFF0) == SC_RESTORE)
{
m_ctrlReadList.Invalidate();
}
but it bugs me that I'm adding code to solve a problem which only happens in such odd circumstances. I can't help thinking that there is something I have missed in the setup which is leading to this behaviour. Can anyone offer any explanation as to what is causing it in the first place?
My explanation is based on the facts of what I have found but this has been a learning experience for me so apologies if I get some of it a little confused, I'm still letting it settle in my mind.
Along with this problem I found another which turned out to be relevant. From the nature of the program I'm writing, my CListCtrls needed fixed width headers. Now that turned out to be another thing I couldn't set up! I just needed to prevent the user from grabbing and resizing the header's dividers or double clicking them to autosize, and of course there is functionality in the CListCtrl based on its child CHeaderCtrl to set this up isn't there? Well apparently not. LVS_EX_HEADERDRAGDROP for example isn't the way.
So I explored trying to capture messages which would allow me to myself, and what do you know, I couldn't! I could trap a few but not the ones I needed. I was looking for HDN_BEGINTRACK and HDN_DIVIDERDBLCLICK. (We won't go into the fact that you HAVE TO deal with both A and W versions of those separately!) The CHeaderCtrl is a child of the CListCtrl but it sends its messages back to the CDialog as the CListCtrl's parent. I tried there using both my list's and 0 as ID which headers apparently use. Many of them just plain didn't appear there at all.
So I created my own CListCtrl class inheriting from CListCtrl, overrode OnNotify and they turned up there. I simply prevented CListCtrl::On Notify from being called for those messages and it worked, no resize functionality at all.
I also played with the Z-order too which could have been relevant. I didn't explain earlier but this and another list are on two tabs, exactly aligned over each other. Selecting the tabs HIDEs and SHOWs each of the lists in turn. The other list had no display problems even when I changed the default display in OnInitDialog to show it at start up.
It was under the problematic one. So changing the Z-order in OnInitDialog where I set them up - did nothing! And to rub it in that second list was also unresizeable by default just as I wanted and I couldn't find out why. Their Properties listed exactly the same and there was nowhere in the code where any different aspect was set manually for either, they were effectively theoretically identical, but practically not so. So frustrating!!!
And the upshot of it is that now that the header resize issue is solved my display problem has vanished too! It looks to me and to a few others out there too who report similar symptoms as myself as though the CListCtrl is another one of the slightly flaky ones and needs a little massaging to get the best out of it.
I hope that makes sense to those of you out there who know this control well. I was surprised how simple the solution was, but it also surprised me that the diagnostic process was so difficult. It may of course come down to the ageing system I work within. Nowadays I do this only for fun and the expense of updating VS from 2005 for occasional use is not a high priority. I am sure that some of the symptoms will not show under other build and run environments but it may be worth having the issue and my solution on record somewhere for Google to find for others.
I have been working on a project in excel for a while and am having problems deploying it to my client. We have (exactly) the same version of excel but when he opens the file the sizing of the components is all wrong. Please see the screenshots below:
When he turns on design mode or clicks and holds the vertical scroll bar, the issue corrects itself for the most part:
But when compared to the original there are still issues, such as the "Rental Start" and "Rental End" labels.
I should also mention that this problem is not isolated to this project. We had some issues with a different one, as well, but never made the connection between design mode and couldn't figure it out. I have tried my IntegralHeight property per a forum post somewhere, as well as double checking that my components are not set to size with cells. Does anyone know why this might be occurring? He has windows 8.1 and I have 7, if that could be the difference.
Note: All controls are ActiveX controls.