[Qgis-developer] Null Value in QLineEdit
Nikhil Murarka
nikhilmurarka14 at gmail.com
Fri Apr 3 16:21:26 PDT 2015
try:
if myDialog.findChild(QLineEdit,"cod_direzione").text() == "":
myDialog.findChild(QLineEdit,"cod_direzione").setText("A")
else:
myDialog.findChild(QLineEdit,"cod_direzione").setText("NOT NULL")
use len(str) instead of str.length()
I think the text is not empty string intially because it work for me.
Also where are you defining this statement ? -some callback function or
__init__
Can you post the complete function ?
On Fri, Apr 3, 2015 at 2:12 PM, <qgis-developer-request at lists.osgeo.org>
wrote:
> Send Qgis-developer mailing list submissions to
> qgis-developer at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
> qgis-developer-request at lists.osgeo.org
>
> You can reach the person managing the list at
> qgis-developer-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Qgis-developer digest..."
>
>
> Today's Topics:
>
> 1. Difference of "import" inside qgis python console and inside
> a python plugin (Luca Mandolesi)
> 2. Re: A plea for plugin authors (Stefan Keller)
> 3. Null Value in QLineEdit (Enrico Fiore)
> 4. Re: Thoughts about multi-type tables in QGIS (Matthias Kuhn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 3 Apr 2015 00:36:44 +0200
> From: Luca Mandolesi <mandoluca at gmail.com>
> To: qgis-developer List <qgis-developer at lists.osgeo.org>
> Subject: [Qgis-developer] Difference of "import" inside qgis python
> console and inside a python plugin
> Message-ID:
> <
> CAHmdnV6dCn19KbaXNUktpSFCM0SxoOArh7tgEX1OwJGFO6a6EA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi to all,
>
> I'm trying to use vispy module inside my python plugin, but a strange thing
> happens:
>
> If I call import vispy inside the Qgis python console the script runs
> properly, but, if I put the "import vispy", at the beginning of my plugin,
> I receive this error [0]
>
> Why inside the Qgis python console a module can be imported, but not inside
> a plugin?
>
> Really, really, strange.
>
> Ideas?
>
> Thanks a lot,
> Luca
>
>
>
> [0]
> Traceback (most recent call last):
> File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 219, in
> startPlugin
> plugins[packageName] = package.classFactory(iface)
> File
> "C:\Users\Windows\Github\pyarchinit_beta_test_dev\pyarchinit\__init__.py",
> line 49, in classFactory
> from pyarchinit_plugin import PyArchInitPlugin
> File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 478, in _import
> mod = _builtin_import(name, globals, locals, fromlist, level)
> File
>
> "C:\Users\Windows\Github\pyarchinit_beta_test_dev\pyarchinit\pyarchinit_plugin.py",
> line 23, in
> import vispy as visp
> File "C:/OSGeo4W/apps/qgis/./python\qgis\utils.py", line 478, in _import
> mod = _builtin_import(name, globals, locals, fromlist, level)
> File
>
> "C:\OSGeo4W\apps\Python27\lib\site-packages\vispy-0.3.0-py2.7.egg\vispy\__init__.py",
> line 34, in
> _parse_command_line_arguments()
> File
>
> "C:\OSGeo4W\apps\Python27\lib\site-packages\vispy-0.3.0-py2.7.egg\vispy\util\config.py",
> line 275, in _parse_command_line_arguments
> opts, args = getopt.getopt(sys.argv[1:], '', argnames)
>
> AttributeError: 'module' object has no attribute 'argv'
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/ebf0c666/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 3 Apr 2015 17:11:19 +0200
> From: Stefan Keller <sfkeller at gmail.com>
> To: "qgis-developer at lists.osgeo.org" <qgis-developer at lists.osgeo.org>
> Subject: Re: [Qgis-developer] A plea for plugin authors
> Message-ID:
> <CAFcOn2-BHjOH0f2w1Vym=sgNh8s_fD3rdQa=
> riW3gsukNuCmFg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Paolo, hi all
>
> Paolo mentioned icons in his plea, section Metadata:
> > * add a proper icon, do not leave the default one; see QGIS interface
> > for a suggestion of the style to be used
>
> There are several places where icons are shown:
> AFAIK there's at least
> 1. QGIS Toolbar: 64x64 pixels?
> 2. Plugins home: http://plugins.qgis.org/plugins/ => 32x32 pixels
> 3. In the QGIS Extensions Dialog: 16x16 pixels
>
> In the QGIS Extensions Dialog actually very few individual icons show
> up like TileLayer, QGIS Cloud or QSpatialite.
>
> My questions:
> A. Are there more places where icons show up?
> B. Are thre recommendations which is the recommended size? 32x32? several
> sizes?
> C. Does anybody know how to make the icon show up in the "QGIS
> Extensions Dialog"?
>
> Yours, Stefan
>
>
> 2015-03-26 14:56 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
> > Il 26/03/2015 14:53, Charles Shapiro ha scritto:
> >
> >> Has anyone else had this difficulty?
> >
> > I remember others had the same problem, but cannot recall how they
> > solved it: anyone?
> > All the best, and thanks for your reply.
> >
> > --
> > Paolo Cavallini - www.faunalia.eu
> > QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 3 Apr 2015 18:03:05 +0200 (CEST)
> From: Enrico Fiore <enricofiore at libero.it>
> To: <qgis-developer at lists.osgeo.org>
> Subject: [Qgis-developer] Null Value in QLineEdit
> Message-ID:
> <2062915558
> .1665451428076985353.JavaMail.httpd at webmail-16.iol.local>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
> I am newbie in python e pyqgis.
> I tried to perform some validation related to a open form action. The
> validation affects when the user click on ok.
> I have to check if a value in a edit text slot is null and in that case
> edit a default value in the form slot. I made different test:
>
> EX1.
>
> if myDialog.findChild(QLineEdit,"cod_direzione").text() == "":
> myDialog.findChild(QLineEdit,"cod_direzione").setText("A")
>
> Results: QGIS doesn't return any error but doesn't set the value "A"
>
> EX2.
>
> if not myDialog.findChild(QLineEdit,"cod_direzione").text().length() > 0:
> myDialog.findChild(QLineEdit,"cod_direzione").setText("A")
>
> Results: return this error
> AttributeError: 'unicode' object has no attribute 'length'
> How i can test if the value in the text edit field i null? and then put
> the default value in the attribute field?
>
>
> Thanks for your attention
>
> Enrico Fiore
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/94adf3e4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 03 Apr 2015 20:12:15 +0200
> From: Matthias Kuhn <matthias at opengis.ch>
> To: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Thoughts about multi-type tables in QGIS
> Message-ID: <551ED7FF.50301 at opengis.ch>
> Content-Type: text/plain; charset="windows-1252"
>
> I think there's a lot of hidden caveats - in QGIS itself as well as in
> plugins - and it would be very hard to find them all and treat them
> appropriately.
>
> Therefore I would prefer not to go for a change in layer semantics in
> terms of that a layer iterator suddenly may return different geometry
> types.
> I'd prefer to re-raise the idea of having a special layer-group type
> that allows to define certain settings on all sub-layers. Adding a
> multi-geometry layer can by default add such a layer.
>
> The difference is an opt-in vs. an opt-out approach.
> Changing the layer geometry type semantic would require to update
> everything that does not want to use multi-geometry behavior (hence
> opt-out). A possibly painful story with lots of side-effects that we
> possibly can't even think of right now.
> The group approach would allow any component capable of handling
> multi-geometry types to add possibilities on group-level. With a good
> API it can be easy to determine if a layer is part of a multitype group.
> And from the group an iterator can be requested and a hierarchical
> setting can be introduced (define defaults at group level, override at
> layer level).
>
> I would strongly prefer the second approach. It should allow to do all
> the cool things and introduce them incrementally without having to deal
> with all the unintended side-effects of a sudden break in semantics.
>
> Do you think there are downsides of this approach?
>
> Best regards,
> Matthias
>
> On 04/02/2015 05:07 PM, Olivier Dalang wrote:
> > Hi,
> >
> > Would it really be more complicated ?
> >
> > I mean, for now, an algorithm that works only with line layers already
> > has to check whether the layer is of type line. That's done before
> > iterating the features.
> >
> > Exactly in the same way, there would be functions to determine whether
> > a layer supports a geometry type or not.
> >
> > Then, there would be functions to iterate a particular geometry type
> > for a layer.
> > This could be done by adding a geometry type argument to getFeatures,
> > and/or by adding specific
> > getLineFeatures/getPointFeatures/getPolygonFeatures functions,
> > probably throwing exceptions if the layer does not support this
> > particular type (shapefile or specific geometry column in postgis).
> >
> > To me it seems not much different from how it works currently, at
> > least from a programmer's point of view. Of course it's quite a change
> > in the API, that's why it's only thoughts for a future QGIS 3 or 4...
> >
> >
> > I don't know Mapinfo at all, but it's good to know there's already
> > some experience somewhere (even if bad). But do you really think the
> > problem is in the principle itself, and not in Mapinfo's implementation ?
> >
> >
> > The things at stake are maybe worth the thought still...
> > The heavy distinction between geometry types is very artificial.
> > There's a lot of very valid representation of real world phenomenons
> > of a certain kind that require different geometry types. Having to
> > distribute those across different layers because of a 25 years old
> > file format is somewhat sad...
> >
> >
> > Olivier
> >
> >
> > 2015-04-02 16:41 GMT+02:00 Bo Victor Thomsen
> > <bo.victor.thomsen at gmail.com <mailto:bo.victor.thomsen at gmail.com>>:
> >
> > As an old MapInfo user/developer my opion is: Don't do it. It has
> > always been a problem in MapInfo and it will be a problem in QGIS
> > - if implemented.
> >
> > A better approach is to have the possibility to let different QGIS
> > layers share some common characteristics (for example labelling).
> > And - of course - clean up the current errors in QGIS when
> > splitting contents of data sources by object types.
> >
> > Regards
> > Bo Victor Thomsen
> > AestasGIS
> > Denmark
> >
> > Den 02-04-2015 kl. 13:52 skrev Olivier Dalang:
> >> Hi,
> >>
> >> In some projects of mine, I work with multiple geometry types in
> >> one postgis table, using a column of type geometry(Geometry,4326).
> >> This is very well supported by postgis.
> >>
> >> It is possible to load such a table in QGIS by manually selecting
> >> the geometry type you want to load. This means that to display
> >> all the features, you need to add the table three times, one for
> >> each feature type.
> >>
> >> This works more or less. There are a few bugs though :
> >> - http://hub.qgis.org/issues/12499 (you can edit other type's
> >> node with the node tool)
> >> - http://hub.qgis.org/issues/12500 (other type's records are
> >> shown in the attribute table)
> >>
> >> This also has some limitations. When having such a setup, it's
> >> pretty sure you'll want to have the same edit forms for all the
> >> layers. You'll also probably want the same filter, the same
> >> labels, the same actions, etc...
> >> The only thing you'd want to be able to define on a geometry type
> >> basis are the symbol (well, even the classification/colors/etc
> >> could be shared) and the label placement.
> >> For now, you must do all settings three times, because of this
> >> bug/feature request :
> >> - http://hub.qgis.org/issues/12303 (copy/paste style from one
> >> geometry type to another)
> >>
> >>
> >> As you see, support multiple geometry types in QGIS is not perfect.
> >>
> >> Of course it's possible to fix the bugs/pr, and there are some
> >> workarounds (postgis view instead of tables) but maybe it's also
> >> worth thinking a bit more in depth about this.
> >>
> >> We could consider point/line/polygons as subcategories/sublayers
> >> of a layer. A shapefile or a mono-typed table would have only one
> >> of those sublayer, but a postgis table could perfectly have the
> >> three. Most of the settings would be defined at the layer level,
> >> while only some settings would be defined at the subcategory level.
> >>
> >> This is probably especially relevant when thinking long term (the
> >> day we support 3D, curves, etc...).
> >>
> >>
> >> What do you think ?
> >> Do you think the relation 1 layer = 1 geometry type will hold ?
> >>
> >> I think we inherited this from the old shapefile format, but most
> >> data sources QGIS handles don't have this limitation. I also
> >> think it does not hold with quite a lot of modern GIS uses
> >> (especially web related, think of openstreetmaps for instance).
> >>
> >> There's this feature request (6th oldest open issue on the
> >> tracker) about postgis geometry collections :
> >> http://hub.qgis.org/issues/167
> >>
> >>
> >> Best,
> >>
> >> Olivier
> >>
> >>
> >>
> >> _______________________________________________
> >> Qgis-developer mailing list
> >> Qgis-developer at lists.osgeo.org <mailto:
> Qgis-developer at lists.osgeo.org>
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org <mailto:
> Qgis-developer at lists.osgeo.org>
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> >
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/8d4122a6/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> End of Qgis-developer Digest, Vol 114, Issue 9
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150403/4da74789/attachment-0001.html>
More information about the Qgis-developer
mailing list