I've been developing the same React Native app for about a year and recently I've noticed that on both iOS simulators, Android emulators, and physical devices, sometimes that little pop up that says "Refreshing" (that comes up when you actually make a change and save) constantly appears, even if I haven't changed anything.
It only happens sometimes and I can usually navigate normally throughout my app (though sometimes it crashes when this is happening, not sure it's related). Sometimes it just randomly stops though. It's very annoying at best and at worst I fear something is not right.
Since it happens on both iOS and Android, I feel like it must be something with React Native? I don't see anything in the logs about it and I haven't been able to find any issues whose solutions fixed things but here are the things I've tried:
Android Studio -> File -> Invalidate Caches...
Cleaning the build folders in XCode and Android Studio
Updating to latest versions (XCode 14.2 and Android Studio Electric Eel)
Restarting Xcode, Android Studio, and my computer
Increasing the Internal and SD Card storage to 1024 MB on an emulator. I'm unable to change the RAM or VM Heap.
Using React Native 0.67.4 and Ventura 13.1 on an M1 MacAir. It also happens on Monterrey 12.6.2 on an Intel Mac.
Anyone have any idea why this might happen? Thanks in advance!
Related
I work on c++ project on VS, and a lot of operations that were fast now super slow. Saving a file could take minutes, intelISense may take forever to show hints, navigating functions takes long time. I tried to reinstall VS 2017, but behavior havent changed. I tried to move to VS 2019, but observe same things. I have 6700k, 32gb ram, Windows 10 with latest updates, both VS installed on NVME M2 drive(around 3000 mb/s write/read), so my PC rather fast. Any ideas how I can solve it? Development sometimes feels unbearable.
EDIT: So, I deleted everything that was remotely close to Visual Studio (VS15-17-19, build tools, Nsight, CUDA integration) and installed clean VS19 installation only with v142 tools for C++. So far(few hours in) it works fine. I dont know what was the problem, but I hope it fixed it. Will report later if lags will return.
I'm working in a project building an application with Computer Vision using C++, OpenCV and Visual Studio. I'm no expert in deploying programs to use them on other PCs.
I've made a program which I need to distribute to a certain amount of people and I can't make it work on all the computers I'd like to. The program was written using Visual Studio 2015, it's an MFC Project and the code is written in C++ since I'm using OpenCV.
When it was finished, I tried to run it on another computer and I realized that it won't open. I looked on the Internet and found out that I needed to statically link the libraries, so I did it. Also, when I was looking for information, I found that Visual Studio 2015 builds its projects so you can run the programs on machines with Win7 to Win10. When I learnt that, I tried to open it on PCs running Windows 7, 8, 8.1 and 10. I tested my program in like 20 computers, give or take.
The results? I couldn't make it work for Windows 7, the error ucrtbase.terminate api-ms-win-crt-runtime-l1-1-0.dll showed every time I tried to open it. It also didn't open in one machine with Windows 8 without showing any error message, but it DID open on most of the machines with Win 8.1 and Win 10. The thing is that "most"; there were some PCs (with Win 8.1 and 10) that I couldn't open my program on. I found that sometimes it would show up in the Task Manager for less than a second and then disappear. The most stressful thing is that it doesn't tell me what the problem is, it doesn't show any error message. It just won't open.
I tried using Dependency Walker (both on my PC and one of those that I couldn't run my program on) to see if there's something missing and I got a reeaaally long list of files that the system couldn't find, here's an example:
List 1/11. Something curious is that my program executes just well on my computer and on those I could open it, even though Dependency Walker (DW) tells me that there might be a problem with it. This indicates me that DW is not finding the exact error I'm having.
Another thing I've tried is to compare the things I have installed on my computer and install them on the one I want to execute my program on. I tried installing .NET Framework 4.6.1 just because VS 2015 says that my project was built using it (and I have it installed in my PC and that other one doesn't. Also I tried with .NET 4.6.1 SDK). Nothing changed.
Just look here:
https://msdn.microsoft.com/de-de/library/ms235299.aspx
The quick-and-dirty way would be to copy the DLLs from your redist directory. For my MS VS 2013 it is hidden under the VS installation directory in:
VC\redist\x86
or
VC\redist\x64
...
which depends on your application.
I have just released a new build of our Command Ops engine, which involved a conversion here from VS2010 to VS2013. I have included the retail vcredist_x86 package and it all seems to work fine for most of our users. However, I have two users running i3 systems - one Win7 Pro and the other Win7 Home Premium. They both report the same issue in that the game app won't launch - in terms that nothing is displayed on the screen. The game app is not listed in the App listing of Task Manager but there is an entry for it in the Processor listing. After 20 seconds another two entries appear in the Processor listing. One of these can be closed down but the other two refuse and can only be got rid of by rebooting. They can launch one of our visual basic apps that come with the install package but none of the visual c++ apps.
My gut feeling is that there is some difference with one or more of the redistributable dlls. Hence my question about whether there are any known differences based on an i3 system. Any advice would be welcome. Thanks.
I'm working on an AIR app that uses a Native Extension for windows that I developed for the same project. The app calls an ANE method called pingFunction and passes it a String containing the IP address where the pingFunction will perform, believe it or not, a ping test.
The application and it's ANE work great on Flash Builder and even after making it a release, they keep working like a charm on the development PC. The problem is that I've tried on two other computers and the application is throwing the following error:
ArgumentError: Error #3500: The extension context does not have a method with the name pingFunction.
at flash.external::ExtensionContext/_call()
at flash.external::ExtensionContext/call()
at com.mycompanyname.myappname::MyAppName/sendPing()[...
At the beggining I thought I had to do with the fact that I was using a DLL I compiled using the Debug configuration on Visual Studio instead of the Release configuration, because I read that sometimes the a debug-version of a DLL can use external DLLs. So, I changed it and rebuilt the whole library as a release build. Sadly for me, I'm still experiencing the same result.
Also, I tried changing the swf-version of both the AIR app and the ANE to the AIR SDK version I'm using (14.0), and got again the same error.
The development computer is running Windows 8.1 and the others, where the app is not working, Windows 7 and Windows 7 Service Pack 1.
Any ideas about why this is happening? Any questions or comments that might lead me to the right track will be deeply appreciated.
Error#3500 is coming because you don't have the required runtime installed on those machines, which is necessary to execute any c++ code .
On your development machine you have visual studio installed and hence you also have msvcr.
Solution of the problem is:
Install msvcr i.e. Microsoft Visual c++ redistribution - 2012 from here.
you need msvcr anywhere you want to run any VS compiled c++ code.
At my shop, the main product app is a mongrel built on MFC, QT and other random things devs have thrown in over the years.
In the current stack, Qt toolkit is on the way out, but still features heavily.
If I have SQL 2005 Management studio open and have to do a full build, it usually hangs a CPU (even after the offending process is taken out back and shot...) during the qt specific parts of the build (Moc'ing and UIC'ing)
has anyone seen anything like this? any ideas what the problem could be?
In my experience, some of these tools are capable of looping forever (qt4: lupdate/lrelease for sure).