I use the next guide: http://msdn.microsoft.com/es-es/library/windows/apps/hh700381.aspx
But connected property don't exist
var red = Windows.Networking.Connectivity.NetworkInformation,
internet = red.getInternetConnectionProfile();
console.log(internet.connected);
That MSDN page is in error--the connected property doesn't exist. (I'll file a bug on that topic!).
If you don't have any connectivity, then getInternetConnectionProfile will return null to begin with.
You can see the correct code in scenario 1 of the Network information sample, http://code.msdn.microsoft.com/windowsapps/Network-Information-Sample-63aaa201. This is where the code in that topic was originally taken, and clearly the two aren't in sync.
Related
This is also logged in the project specific issues list... https://github.com/osm-search/nominatim-ui/issues/194
I'm setting up a Nominatim server, and as part of that, I've set my /theme/config.theme.js file with the defaults I want (Default Lat/Long/API Endoint location).
Unfortunately, that seems to not be being read by the nominatim-ui - so no matter what value I set, this isn't taking effect.
config.theme.js looks like:
Nominatim_Config.Nominatim_API_Endpoint = 'http://192.168.1.2';
Nominatim_Config.Page_Title = 'Local Nominatim Server';
Nominatim_Config.Reverse_Only: true;
Nominatim_Config.Reverse_Default_Search_Zoom: 15;
Nominatim_Config.Map_Default_Lat: -33.85237;
Nominatim_Config.Map_Default_Lon: 151.21129;
Nominatim_Config.Map_Default_Zoom: 16;
and yet, the Nominatim API endpoint is still showing http://localhost/nominatim/, and not taking any default position changes.
I've tried changing the config.defaults.js as well, to no avail.
Any ideas why these changes aren't being picked up by nominatim-ui?
For the record, the Web server itself is running (and answers reverse queries when submitted), so that is fine - I'm just struggling to get the UI to point to the correct location. The Documentation simply says "change the config.theme.js", but that isn't working for me.
As a test, I've set the permissions to 777 (fully open), so that doesn't seem to be it. Obviously want to set those sensibly when I'm working.
Current release I'm using is latest (v3.2.8)
https://github.com/osm-search/nominatim-ui
Ubuntu 22.04.2 (LTS) fully patched
Hosting via NginX web interface (1.18.0)
Nominatim is also latest (4.1.0) - and again, that's working when I query directly.
OSM correctly imported for my region (Aus/Oceania), and db import successfully completed.
EDIT:
Since my comment below mangles code, updating here with syntax formatting:
OK, thanks to #ionia on the github project - the syntax wasn't correct (had : instead of = so the file had invalid syntax, and thus wasn't used at all.
Corrected file looks like:
Nominatim_Config.Nominatim_API_Endpoint = 'http://192.168.1.2';
Nominatim_Config.Page_Title = 'Local Nominatim Server';
Nominatim_Config.Reverse_Only = true;
Nominatim_Config.Reverse_Default_Search_Zoom = 15;
Nominatim_Config.Map_Default_Lat = -33.85237;
Nominatim_Config.Map_Default_Lon = 151.21129;
Nominatim_Config.Map_Default_Zoom = 16;
This is my very first attempt to work with Xamarin studio with Realm (to make app for both iOS and Android) and I am stuck at this situation since last 24 hours.
My online database-table has 30,000 rows. Earlier when I used to work in Android studio, I used to import those rows in app's 1st run with the help of JSON, GSON and insert into SQLite db.
But I am unable to do so in Realm & Xamarin. I know, I have not provided any code snippet (my effort), but honestly even after searching a lot about this, I couldn't find how should I proceed?
I've already answered that in the Github issue, but in case someone else stumbles across it, the best way to do that without blocking the UI thread, is to use the Realm.WriteAsync API. Basically, you'll do something like:
var items = await service.GetAllItems();
// I assume items are already deserialized RealmObject-s
var realm = Realm.GetInstance();
await realm.WriteAsync(r =>
{
foreach (var item in items)
{
r.Manage(item);
}
}
/* Data is loaded, show message or process it in other ways */
One thing to note is that within the WriteAsync lambda, we're using the r instance and not the original realm one. The reason is that because realms are not thread safe and the asynchronous write will happen on another thread, so it implicitly creates another instance and passes it as an argument of the action parameter.
So I'm seeing some bizarre behavior in an appwidget that I wrote.
The widget itself is quite simple - it reads a few values from persistent storage and then displays them as text. Nothing fancy in the layout - just a FrameLayout root element with some Linear Layout and TextView children.
The widget has a simple configuration activity associated with it.
The bizarre behavior is that the widget will initially show "Problem Loading Widget" after the user closes the configuration activity, and then after a few seconds it shows a "Google Sound Search" button (and clicking on the button actually does launch Google Sound Search). Then, after a few more seconds, it finally shows the expected display.
I am away from my code right now, so I'll have to wait until tonight to post code snippets. However, in the meantime, can anyone provide some insight into how such a thing could happen? Has anyone else ever experienced this? How could another widget "hijack" mine?
Thanks,
-Ron
Here are some screenshots:
There are a couple of issues with your widget and there are answers to all of them (although you didn't post any code so some of my statements are based on assumptions):
"Problem loading widget": this is the default view Android uses before the widget is initialized and the layout updated. Simply add the following line to your widget xml configuration (to show a loading message instead of the problem message):
android:initialLayout="#layout/my_cool_widget_loading_message"
If the widget shows the wrong layout then you probably have an issue in the widget's onReceive method. onReceive is called for all the widgets no matter whether the broadcast is for that specific widget. Android's AppWidgetProvider filters the broadcasts by appwidget Id and dispatches to the other methods (like onUpdate).
See also: https://developer.android.com/reference/android/appwidget/AppWidgetProvider.html#onReceive(android.content.Context, android.content.Intent).
If you override onReceive (which I assume you do), you need to call through to super.onReceive(Context, Intent) to make sure your other methods don't get calls meant for other widgets.
Now for the configuration of the widget. If you follow the Google documentation then it will all work nicely. The only improvement I'd do is what my other answer that you reference suggests (https://stackoverflow.com/a/14991479/534471). This will NOT send out two broadcasts. The setResult()/finish() part does only terminate the config Activity and let Android know whether to actually add the widget or not (depending on whether the result is RESULT_CANCELED or RESULT_OK.
From your own answer I can see why your code wouldn't work. The code is:
Intent intent = new Intent();
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {mAppWidgetId});
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, intent);
sendBroadcast(intent);
finish();
First of all there's no need to add the appWidgetId twice, use the AppWidgetManager.EXTRA_APPWIDGET_IDS version and you're good. Second you're using the same Intent to return as a result for the Activity. AFAIK it's not documented what happens when you do set an action on that Intent but my experience with Android widgets is that you need to stick exactly to the documentation or you'll end up having strange issues (like the ones you encounter). So please use two different Intents.
Activity result:
Intent resultValue = new Intent();
resultValue.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, resultValue);
finish();
Broadcast:
Intent intent = new Intent(AppWidgetManager.ACTION_APPWIDGET_UPDATE, null, this, MyWidget.class);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {mAppWidgetId});
sendBroadcast(intent);
ok, so I figured it out. Posting here in case anyone else runs into this. I think that the Android Developer docs are a little misleading here.
The problem was that in my configuration Activity, I had this code at the end:
Intent intent = new Intent();
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {mAppWidgetId});
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, intent);
sendBroadcast(intent);
finish();
Providing an intent with the extra EXTRA_APPWIDGET_ID is recommended by the documentation provided by google.
However, that same document says that you have to update the widget's view by creating a RemoteView and calling AppWidgetManager.updateAppWidget() like so:
RemoteViews views = new RemoteViews(context.getPackageName(),
R.layout.example_appwidget);
appWidgetManager.updateAppWidget(mAppWidgetId, views);
I didn't like the idea of placing the presentation logic in both the configuration activity and the widget class, so I instead decided to broadcast an intent at the end of the configuration activity to tell the widget to redraw itself. That's why I have setResult() AND sendBroadcast() at the end of the activity. The documentation further states that the onUpdate() callback will not be called when using a configuration activity. So this seemed neccessary. I added the ACTION_APPWIDGET_UPDATE and the EXTRA_APPWIDGET_IDS to the intent so that it would trigger the onUpdate() method. This practice was recommended by this SO answer (albeit without being included in the activity result intent - but I tried separating the two and it had no effect).
Now I'm not certain exactly how the "Google Sound Search" widget got in there, nor do I fully understand the mechanics of how the intents interacted to produce the observed results. However, as soon as I replaced my code above with the code stated in the docs, the widget was updated properly.
Intent resultIntent = new Intent();
resultIntent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, resultIntent);
finish();
This seems to contradict the documentation's statement that the configuration activity must update the widget's view. Simply providing the configuration activity result as below triggers the onUpdate() method in the widget, thus allowing the widget to redraw itself. I confirmed the behavior on an emulator running API 23 and also on a Samsung device running Samsung's android flavor.
I am having a problem that has been reported here and elsewhere before: not being able to change the recurrence pattern on a master via EWS. First, I tried using the old proxy classes against E2010. I have also now tried using the 2.0 Managed API, to no avail. The error FWIW is "Set action is invalid for property". E.g. I want to change the recurrence end date, or the number of recurrences.
In an MSDN post from 2008, Dave Stirling mentions that only the organizer should be able to do this. This is a problem for me because my server application uses a single, full-access id to manage all of the room resource calendars in an enterprise. With this user I can delete appointments on any calendar, regardless of organizer, and I can certainly update a single instance of a recurring series, e.g. changing its start time. I don't understand why manipulating the recurrence pattern would be prohibited because I'm not the organizer while manipulating an instance's spot on the calendar, or deleting the entire series would not be.
I have also tried using impersonation, so that I am (I think) impersonating the Room resource itself, in which case, even though I am not the organizer, I feel I must be the owner of the appointment, and hence entitled to do whatever the heck I want to it. I guess Exchange feels differently. Managed API code below, FWIW.
TIA,
Paul
var Svc = new ExchangeService(ExchangeVersion.Exchange2010, TimeZoneInfo.Local);
Svc.CookieContainer = new CookieContainer();
Svc.Credentials = new WebCredentials(m_SvcUser, m_SvcPswd);
Svc.EnableScpLookup = false;
Svc.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, m_RoomMB);
Svc.AutodiscoverUrl(m_RoomMB, RedirectionCallback);
var Master = Appointment.Bind(Svc, new ItemId(args[0]), m_Props);
if (Master.Recurrence.NumberOfOccurrences != null)
Master.Recurrence.NumberOfOccurrences--;
else
Master.Recurrence.EndDate = DateTime.Now;
Master.Update(ConflictResolutionMode.AlwaysOverwrite, SendInvitationsOrCancellationsMode.SendToNone);
To close this out, I will report that I opened this question as a support issue after getting no responses here or on MSDN. The net of it is this: Exchange does not permit an attendee (in this case a conference room I am impersonating in EWS) to change the recurrence "blob." This is by design. The only user who can do so is the organizer. I'm not sure this really makes complete sense to me, but I don't have much say in the matter, now do I?
I've received an error report from a client recently and am having no luck resolving it. I'm hoping someone can give me some insight to what may be wrong.
The error seems simple enough:
Csla.DataPortalException: DataPortal.Delete failed (System.InvalidOperationException: Sequence contains more than one element at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source)
Here is my DataPortal_Delete method, which takes the FileId (PK) as a parameter.
private void DataPortal_Delete(SingleCriteria<File, Guid> criteria)
{
using (var ctx = ContextManager<Ronin.Data.RoninDataContext>
.GetManager(Database.ApplicationConnection, false))
{
var data = ctx.DataContext.Files
.Single(row => row.FileId == criteria.Value);
ctx.DataContext.FileSources.DeleteAllOnSubmit(data.FileSources);
ctx.DataContext.Files.DeleteOnSubmit(data);
ctx.DataContext.SubmitChanges();
}
}
First thing I check was to see if there was another record with the same FileId (although being the primary key, this should be impossible). All FileIds were in fact unique. I launched the application connecting to the client database and tried to delete the record and it worked without any issues. The IT guy at the client site used the "Problem Step Recorder" to send me step by step screenshots of the actions taken by the user. Nothing out of the ordinary, and when he used a different machine, he was able to delete the record without any errors. Apparently this only happens when the application is run in Windows 7.
That said, any ideas as to what could be causing this?
Assuming the call to Single is the source of the problem, instead of:
ctx.DataContext.Files.Single(...)
change the code to allow the return of multiple rows from that query and then log what it's returning when it returns more than one row. This should point you toward your "duplicate" data problem.
Another thing to look at is the SQL that is being generated behind the scenes. Not sure that will help, but it can't hurt. I don't know your data model, so I can't understand your code as well as I would like to.
If it only happens in Windows 7 then this might be cause by the OS. Have you tried it on Vista? Vista's environment is simmilar on Windows 7. You can also use Windows Virtual PC + XP Mode. This is a virtualization application specially designed for Windows 7 to let users run applications like they use to in Windows XP. Note: XP Mode requires virtualization capable processor.
I had the same exception when deleting one entity. The problem turned out to be a foreign key relation defined in the dbml-File. So this was the reason for the exception in my case.
After I removed that it worked to delete the record (and I didn't want to cascade delete the records from the other table, I just need to find out how to configurate linq-to-sql to just set the foreign key column to null)