This is tidier than using #ifdefs in the same common file and also
ensures that initializing wxLocale affects wxUILocale too, which will be
important for compatibility when the code elsewhere is modified to use
wxUILocale::GetInfo() instead of wxLocale::GetInfo() in the upcoming
commits.
This commit is best viewed with --color-moved git option.
This will allow using this class in the library code too.
No real changes yet, this is a pure refactoring.
This commit is best viewed using git --color-moved option.
Fix
'friend' keyword needs 'class'
error introduced by 035c29e6a2 (Make wxRescaleCoord() safer by requiring
explicitly using From/To, 2021-07-13) which broke the build with gcc
4.4.7 used under CentOS 6.
Closes https://github.com/wxWidgets/wxWidgets/pull/2450
Use the same scaling function as elsewhere instead of using
ceil/floor().
Provide wxRescaleCoordWithFrom specialization for int to allow using it
with just single coordinates too.
They're probably not that useful in application code, which should just
use wxDPIChangedEvent::Scale() instead, so move them to a private
header instead of making them part of the public API.
Move this function, and the associated constant, to common code.
This required moving wxSpinCtrlDouble::Create() implementation to the
source file, but there are no real changes.
We already did it just before processing the state change event, but
this was too late, as the object could have been already deleted by then
and this actually happened with the example from wxWebRequest
documentation.
Do it earlier now, as soon as the request becomes active, which normally
happens when Start() is called, and keep the reference until the event
is processed after the request reaches one of the final states
(completed, failed or cancelled).
Add a unit test checking that deleting the wxWebRequest object doesn't
prevent the request from running to the completion any more.
If a wxWebRequestCURL object is canceled or deleted before its transfer
is complete, we need to manually close its active socket. Record each
transfer’s active socket in wxWebSessionCURL::SocketCallback so can use
it if needed.
Previously, this was done using curl_easy_getinfo, but this required
some compile time and run time checks and could fail in some specific
cases. Recording the socket ourselves significantly simplifies the code
and should always work.
When using the socket poller implementation using wxEventLoopSource
objects to monitor sockets, the operation
wxEventLoopBase::AddSourceForFD(... can sometimes return NULL. In these
cases the socket will not be monitored as needed. The only option seems
to be to cancel the transfer and report a failure
Previously wxWebRequestCURL objects were canceled by removing their
CURL easy handle from the CURLM multihandle. Unfortunately the really
only pauses the connection and does not truly cancel it. This commit
tries to stop the transfer by retrieving the active socket from the CURL
handle for the transfer and closing it.
There are some complications in doing this because the option curl uses
to get the socket have changed over the years. A combination of compile
time and run time checks are used to use the appropriate options to get
the socket. However in the case of 64bit windows using a curl version
older than 7.45.0 simply won’t have an usable option. In this case,
it seems nothing can be done.
At various points in a transfer being managed by the wxWebSessionCURL
class we need to perform operations on a wxWebRequestCURL object.
However it’s possible for the request object to be deleted while the
transfer is in progress.
To ensure that the request objects are valid, keep track of the request
objects with a hash map. Objects are added to the map when a transfer is
started and removed when the transfer is complete or in the request’s
destructor.
Currently for wxWebRequestCURL objects using memory storage, a download
is processed by appending to a wxMemoryBuffer each time the write
callback is called. For a large transfer, this can result in many, many
reallocation calls and can block the main application.
This commit uses the progress callback for wxWebRequestCURL objects
added in a previous commit to set a minimum size for the buffer as soon
as it is known.
This commit adds a progress callback for use with wxWebRequestCURL
objects. This has some complications because over the years curl has
changed the signature of the callback.
A combination of compile-time and run-time checks is used to make sure
the appropriate callback and preferred return value are used.
Instead of having wxWebSessionCURL run a worker thread that uses curl
to monitor and process network activity, set up a separate socket
poller class to monitor socket activity. The socket poller class will
throw an event back to wxWebSessionCURL when it detects activity on the
sockets so that it can tell curl to process the activity in the main
thread.
Semantics of this function wasn't really clear and it was used only
once, so just inline it at the point of use and define better what
happens for various states there.
Also use a switch rather than testing for individual states to make sure
this code is updated if another state is added in the future.
No real changes.
Under MSW, don't set the state to State_Cancelled as soon as Cancel()
was called, as the request was still used from the other threads
afterwards, resulting in race conditions and crashes.
Fix this by just removing the SetState(State_Cancelled) call from the
main thread, as it was redundant anyhow. This also makes the behaviour
correspond to the documentation, which indicates that Cancel() works
asynchronously.
Also ensure, for all backends, that we actually cancel the request only
once, even if public Cancel() is called multiple times. This required
renaming the existing wxWebRequestImpl::Cancel() to DoCancel().
It's better not to have this method in the public class, even if it
means that we need to pass a wxWebSessionImpl object to wxWebRequestImpl
ctor explicitly now.
No real changes.
It's up to the application code to decide how it handles the HTTP status
codes it gets back from server, there is no need to have a special
method for handling them in wxWebRequest itself.
We also shouldn't skip downloading the response body just because it was
unsuccessful, we may still need it (e.g. it's very common to return the
detailed error description in a JSON object in the message body when
returning some 4xx error), so don't do it in wxMSW implementation and
add a test verifying that we still get the expected body even for an
error status.
Also improve wxWebRequest::State values documentation.
This is helpful when trying to understand what is going on, especially
because CFNETWORK_DIAGNOSTICS, which is supposed to do the same thing at
native level, doesn't seem to work (at least under 10.14).
This is shorter and doesn't imply that just the name (and not the full
path) is being returned.
Also rename wxWebResponse::GetFileName() to GetDataFile() for the same
reasons and for consistency. And document this previously undocumented
method.
Also use critical section instead of a mutex, as this is more efficient
under MSW.
Main purpose of this commit is to make it clear that this mutex/critical
section is only used together with the data from the same struct.
No real changes.
Check that current state is State_Idle in wxWebRequest itself only once
instead of doing it in 2 (out of 3) wxWebRequestImpl implementations.
Also assert if this is not the case instead of silently doing nothing
which would surely be more difficult to debug.
Using shared pointer seems to be ill-advised here, the stream shouldn't
be shared as it's going to be used by wxWebRequest itself and can't be
used by the application code in parallel, so the ownership transfer
semantics is more appropriate.
We could take a wxScopedPtr<> instead, but wx API takes ownership of raw
pointers everywhere else, so do it here too.
Incidentally fix a bug with calling IsOk() on a possibly null pointer.
Don't force the application code to deal with wxObjectDataPtr<> or,
worse, calling {Inc,Dec}Ref() manually by hiding it inside the wx
objects themselves and giving the value-like semantics to them.
There should be no real changes in the behaviour, but the API does
change significantly. Notably, wxWebRequest is not a wxEvtHandler itself
any longer, as this would be incompatible with the value semantics, and
an event handler needs to be specified when creating it, so that it
could be notified about the request state changes.
Having wxWebSessionFactory part of the public API implies keeping
compatibility with the possible ways of implementing it which is too
restrictive for no good reason, so move this class to the private header
and don't document it nor wxWebSession::RegisterFactory() (which is now
private).
This is not needed any longer after the changes of the last commit.
Note that the (still existent) public wxGetDisplaySizeMM() didn't use
this function, but used PPI instead.
Don't try computing the PPI ourselves from the physical size and the
number of pixels, this doesn't work and nobody else does it like this.
Just assume that we're using standard PPI by default and use
toolkit-specific functions for the platforms with support for high DPI.
In a native up-down control hexadecimal numbers are always unsigned (see
UDM_SETBASE message documentation) so we need to prevent:
- Setting a range including negative values if base == 16.
- Setting base != 10 if current range includes negative values.
See #18805.
