Microsoft Excel

Herbers Excel/VBA-Archiv

Informationen und Beispiele zum Thema Werkzeug
BildScreenshot zu Werkzeug Werkzeug-Seite mit Beispielarbeitsmappe aufrufen

Nächste Zelle mit Zahl in einer Zeile suchen

Betrifft: Nächste Zelle mit Zahl in einer Zeile suchen von: Ben
Geschrieben am: 09.07.2015 19:21:47

Hallo :)

leider konnte mir google nicht die passende Lösung liefern und da ich hier bereits in der Vergangenheit super Antworten und Lösungen erhalten habe, wollte ich euch ein weiteres Mal belästigen. :)

Ich versuche in einer Zeile die nächste Zelle mit einer Zahl zu finden.
Wenn ich jetzt z.B. nach einem Bestimmten Wort suche, würde ich die Zeile mit "find" und dem entsprechenden Wort suchen. Jetzt möchste ich aber nicht nach einem festen Wert suchen sondern nach der nächsten Zelle die eine Zahl enthält.

Beispiel:

A B C D E F G H
1 u u u f u 9 9 9

In diesem Beispiel würde ich in Zeile 1 die 9 als erste Zahl haben und die steht in Spalte F. Ich möchte also F als Ergebnis haben.

Versteht ihr was ich meine? :)

Vielen Dank und Gruß
Ben

  

Betrifft: mit AGGREGAT() und ADRESSE() ... von: der neopa C
Geschrieben am: 09.07.2015 19:29:15

Hallo ben,

... so: =LINKS(ADRESSE(1;AGGREGAT(15;6;SPALTE(1:1)/ISTZAHL(1:1);1);4);1)

Gruß Werner
.. , - ...


  

Betrifft: einfacher von: WF
Geschrieben am: 09.07.2015 20:35:31

Hi,

folgende Arrayformel:
{=ZEICHEN(VERGLEICH(WAHR;ISTZAHL(1:1);0)+64)}

WF


  

Betrifft: AW: einfacher von: Ben
Geschrieben am: 09.07.2015 21:32:24

Hallo :)

vielen dank schonmal :) werde es gleich mal ausprobieren.

geht das ganze auch irgendwie über vba? :)


  

Betrifft: VBA lehne ich ab - sollte kein Problem sein von: WF
Geschrieben am: 09.07.2015 21:55:07

.


  

Betrifft: einfacher? ist Ansichtssache; kürzer? ... von: der neopa C
Geschrieben am: 10.07.2015 09:16:49

Hallo WF,

... ja, wobei noch kürzer wäre ja: {=ZEICHEN(VERGLEICH(1;1*ISTZAHL(1:1);)+64)}

Doch festzustellen ist, dass Du meinen Flüchtigkeitsfehler nicht bemerkt hast und diesen in Deiner Lösungsformel selbst verfallen bist. Also um ADRESSE() wird man bei einer Formellösung wohl nicht umhin können, wenn man auch Zahlen nach Spalte Z finden will. Derartige Betrachtungsweise hatte ich mal von Dir gelernt, warum weichst Du das jetzt wieder selbst auf?

Meine korrigierte Formel (ich bin nun mal auf MATRIX-freie Formeln mit AGGREGAT() eingestellt) wäre jetzt so:

=WECHSELN(ADRESSE(1;AGGREGAT(15;6;SPALTE(1:1)/ISTZAHL(1:1);1);4);ZEILE(A1);"")

Und im Bedarfsfall das ganze noch mit WENNFEHLER() "geklammert"

Aber wie auch immer, eine Formellösung interessiert hier ja den Fragesteller sowieso nicht

Gruß Werner
.. , - ...


  

Betrifft: AW: einfacher? ist Ansichtssache; kürzer? ... von: Josef B
Geschrieben am: 10.07.2015 11:52:48

Hallo Werner

Natürlich ist deine Variante einfacher, da man diese Formel normal abschliessen kann.

Bei deinem Beispiel kannst du noch in der Funktion WECHSELN bei "Alter Text" direkt eine 1 eingeben.
Zeile(A1) ist da nicht nötig, weil du ja in der Funktion ADRESSE die Zeile auch fest vorgibst.
Und noch eine Variante die so nur dank der Funktion AGGREGAT(.. möglich ist.

=WECHSELN(ADRESSE(1;AGGREGAT(15;6;SPALTE(1:1)/1:1^0;1);4);1;"")

Gruss Sepp


  

Betrifft: wieder ein feine Idee Deinerseits ... von: der neopa C
Geschrieben am: 10.07.2015 12:17:34

Hallo Sepp,

... damit meine ich natürlich das Potenzieren mit 0. Einfach super!

Gruß Werner
.. , - ...


  

Betrifft: fiel mir doch noch gerade ein ... von: der neopa C
Geschrieben am: 10.07.2015 13:02:38

Hallo Sepp,

... das 0 auch eine Zahl ist, die gesucht werden könnte.

Schade. Aber eine feine Idee war es trotzdem!


Gruß Werner
.. , - ...


  

Betrifft: Wenn auch Nuller vorhanden... von: Josef B
Geschrieben am: 10.07.2015 13:39:40

Hallo Werner

.. dann so:

=WECHSELN(ADRESSE(1;AGGREGAT(15;6;SPALTE(1:1)/(1:1<"");1);4);1;"")

Gruss Sepp


  

Betrifft: wie bezeichne ich denn das nun wieder .... von: der neopa C
Geschrieben am: 10.07.2015 15:46:31

Hallo Sepp,

... ist einfach vom Feinsten.

Bist Du da wirklich erst Heute drauf gekommen? Oder hast Du das aus einen Deiner vielen Schubläden gezogen? In diesen würde ich dann schon gern mal stöbern wollen ;-)

Ein schönes WE Dir, Euch!

Gruß Werner
.. , - ...


  

Betrifft: ja, das kommt aus der Schublade o.w.T. von: Josef B
Geschrieben am: 10.07.2015 16:56:21

Gruss Sepp


  

Betrifft: Das ist wieder mal ein schönes Bsp für den ... von: Luc:-?
Geschrieben am: 11.07.2015 23:56:24

…Irrglauben, dass MatrixFmln, speziell 1zellige, irgendwie rechen­intensiver wären als solche, die ohne diese Kennzeichnung auskommen, Werner;
dass das ein Irrtum ist, hat man euch mehr oder weniger „reinen“ Fml-Freaks schon verschie­dentlich nahezubringen versucht, offen­sichtlich ohne Erfolg…
Bei (hier: 1zelligen) MatrixFmln wdn 2 Berechnungsebenen benötigt, 1× die Fml selbst, die alle Ergebnisse berechnet, und dann die Xl-Steuerung, die die Entscheidung darüber trifft, welches dieser Ergebnisse angezeigt bzw (weiter-)verwendet wdn soll. Diese kann auch in die Daten­Bereitstellung eingreifen, wie das bei Logik-Fktt wie ISTZAHL, WENN und auch INDEX (mit unter­schied­licher Wirkung) offen­sichtlich der Fall ist (wie sich das auswirkt, hängt von der Pgm­mierung der jewei­ligen Fkt ab!).
Insofern dürfte WFs Fml (meinethalben mit deiner Änderung, obwohl die einen größeren Zeichen­Vorrat zur Folge hat!) nicht nur die kürzeste, sondern auch die perfor­man­teste und last not least auch die dem normalen Nutzer­Verständnis zugäng­lichste sein. Und immer­hin bemüht deine Fml gleich 6 Xl-Fktt, die intern von AGGREGAT aufgerufene 7. nicht mitgerechnet. WFs Fml verwendet nur halbsoviel! Am Schnellsten dürften übrigens immer noch rein arithme­tische Grund­Operationen sein, also +, -, *, /. Alle Vgls­Operationen (und -Fktt) wdn dagg auf eine Vielzahl einfachster Bit-Operationen rück­geführt!
Mir scheint hier allmählich eine, sachlich oftmals unbegründete, AGGREGAT-Euphorie um sich zu greifen, die schon an Feti­schismus grenzen mag.
Wenn's nur auf die Vermeidung der MatrixFmlForm (die {} muss man ja nicht mal selber schreiben!) ankäme, würde ich außer Konkurrenz ohnehin UDFs verwenden, bspw mit folgender Fml:
=ZEICHEN(64+VERGLEICH(Compute(RinMxList(A1:H1;-2;1));A1:H1;0)) → (Diese UDFs vertragen keine langen Zeilen!)
Das wären dann 2 XlStandardFktt und 2 UDFs → macht insgesamt 4 Fktt. Und rein vom FmlText her ist die auch noch 4 Zeichen kürzer als Sepps universelle Fml mit eben­soviel Fktt (die AGGREGAT-interne 5. nicht mitge­rechnet). Aber auf Nota­tions­kürze kommt's ja primär nicht an.
Nebenbei, man kann u.A. auch TEILERGEBNIS mit einer kleinen Zusatz-UDF in seiner Wirkung noch so verbessern, dass auch Fehlerwerte nicht mehr stören (vgl hier).
Gruß, Luc :-?

Besser informiert mit …


  

Betrifft: glauben und speziell irren ist menschlich … von: der neopa C
Geschrieben am: 12.07.2015 14:24:11

Hallo Luc,

... somit ist auch „Irrglauben“ menschlich. Wer war und ist davon schon wirklich völlig frei?

Ich jedenfalls habe und werde nie von mir behaupten, dass ich nicht irre oder so manches Mal „Irrglauben“ aufgesessen war, bin und möglicherweise sein werde. Ich denke auch, dass sich daran mit zunehmenden Wissen und Erfahrungen nicht viel ändern wird und kann, zumindest nicht was mich angeht. Hoffen tue ich es natürlich immer.

Irrglauben lässt sich nach meinem „Glauben“ jedoch nur durch überzeugende Argumentationen auf Basis realistischer und eindeutiger Belege überwinden. Das hoffe ich, um nicht zu sagen glaube ich.


Zurück von den allgemeinen zu den spezifischen Aussagen hier im thread. Dazu meine Fragen an Dich:

- Wer hat wo hier im thread geschrieben, dass die Matrixformel, die WF vorgeschlagen hat, rechenintensiver wäre, als eine AGGREGAT()-Formel-Lösung? Wieso behauptest Du das also?

- War im thread bisher nicht nur die Rede von „einfacher"? Und war meine Aussage dazu nicht, dass dies Ansichtssache sei? Und ob einfacher oder nicht gibt es im thread derzeit 4 Meinungen mit dem momentanen außerdem nichtssagenden Stand 2:2.

- Warum hast Du meinen Hinweis völlig ignoriert, dass auch eine erste Zahl rechts von Z1 stehen könnte und gefunden werden sollte? Allein dadurch ist Dein hier eingebrachter „Beweis" für Deine Aussage als solcher schon nicht mehr geeignet. Darüber hinaus ist es mE für einen Nachweis unzulässig, von einem (noch dazu unbewiesenen) Einzelfall auf den allgemeinen Fall zu schließen, wie Du es getan hast. Denn Deine Aussagen sind noch kein Beweis dafür, dass AGGREGAT()- Formeln rechenintensiver wären, als wirklich vergleichbare „echte“ Matrixformellösungen.
Richtig ist dagegen (wahrscheinlich), dass eine Kombination von mehreren Funktionen in einer Formel rechenintensiver sein kann, als eine MARIXformel die mit weniger auskommt und eine Bereichseingrenzung günstiger sein kann, als eine Auswertung über den gesamten Spalten- bzw. Zeilenbereich. Aber diese Meinungen vertrete ich selbst auch schon lange. Das musst Du mir also nicht beweisen.

- Wer bezweifelt Deine Aussage: "Am Schnellsten dürften übrigens immer noch rein arithme¬tische GrundOperationen sein ..."? Ich jedenfalls nicht. Und Sepp (Josef B) sicherlich auch nicht. Ganz im Gegenteil, er ist derjenige unter den von Dir als „reinen“ Formelfreaks Bezeichneten, welcher schon sehr oft kompliziertere Formel so vereinfacht hat, dass sie auch effektiver sein könnten.

- Warum meinst Du, dass Deine UDF-Lösungen immer und überall die geeigneteren sind? Das Du mit Deinen UDFs eine viel komplexere Anwendungsbreite erzielen kannst steht doch nicht zur Diskussion. Dass Du mit diesen Formellösungen erzielen kannst, die mit Standardfunktionalität nicht oder nicht ohne unvertretbaren Aufwand erreichbar sind, hab ich nie und werde ich auch nie bestreiten. Allerdings habe ich sehr wohl das eine oder andere Mal aufzeigen können, dass es auch ohne diese gehen kann. Und diese waren deswegen nicht oder auch nicht viel komplizierter zu realisieren.

- Wieso schreibst Du von einer „AGGREGAT-Euphorie“? Von einer solchen kann doch nicht die Rede sein, wenn zumindest hier im Forum momentan nur Einer (in dem Fall offensichtlich ich) von einer solchen befallen zu sein scheint. Oder gibt es in anderen deutschsprachigen Foren noch mehr davon? Würde mich schon interessieren, wer das ist.

Wobei ich auch hier im Forum schon feststellen konnte, dass offensichtlich der eine oder andere sich mit dieser Funktion seither mehr beschäftigt hat, als das bis vor kurzem noch der Fall war. Und ich freue mich natürlich, dass Sepp (Josef B) meine Argumentation unterstützt. Und erst Recht freue ich mich, wenn für Fragesteller meine entsprechenden Formellösungsangebote auch so nachvollziehen waren, dass sie diese an ihre Verhältnisse gut anpassen konnten. Jedenfalls haben dies mir erst in der vergangenen Woche zwei Fragesteller so geschrieben. Gefreut habe ich mich auch, als ich vorhin eine AGGREGAT()-Formellösung von dem anderen Sepp hier im Forum lesen konnte.


Ich glaube jedenfalls weiter daran, nein besser ich hoffe, dass die von mir als MATRIX()funktional(ität)sformeln bezeichneten Lösungsformeln und oder Lösungsalternativen noch einigen mehr Excelnutzern eine Hilfe sein können und werden. Ich bin weiter davon überzeugt, dass diese Art Formeln auch so manche "mentale Schranke" gegenüber Matrixauswertungen eher überwinden können, als wie diese sich noch immer bei (zu) vielen bei „echten“ MATRIXformelösungen zeigen.

Und erst wenn man Matrixformellösungen (ob in "echter" oder als Funktionalitätslösungen) wirklich beherrscht, ist man mE in der Lage über effiziente Problemlösungen nachdenken zu können und solche in Angriff zu nehmen. Und solche können mitunter sogar ganz simple aber gute Hilfszellenlösungen oder eben auch UDF-Formellösungen sein, um nicht gleich gänzlich von VBA-Lösungen zu sprechen. Bis dahin ist aber für viele, auch für mich, noch eine weiter, teils steiler und steiniger Weg.


Gruß Werner
.. , - ...


  

Betrifft: Wer liest das ? von: WF
Geschrieben am: 12.07.2015 15:16:07

.


  

Betrifft: Du musst es ja auch nicht lesen owT von: der neopa C
Geschrieben am: 12.07.2015 15:42:29

Gruß Werner
.. , - ...


  

Betrifft: genauer: keiner muss und brauch es tun, außer ... von: der neopa C
Geschrieben am: 12.07.2015 15:52:54


... evtl.Luc, der mich ja auch angeschrieben hat.

Gruß Werner
.. , - ...


  

Betrifft: dann schick ihm ne Email von: WF
Geschrieben am: 12.07.2015 16:01:04

.


  

Betrifft: Auch, wenn WF meint, dass das Keinen … von: Luc:-?
Geschrieben am: 12.07.2015 22:04:01

…interessieren würde, ihn hat's ja offensichtlich, Werner, ;-]
doch noch eine AW im Forum. Zu deinen Pktt:
1…3. Meine Formulierung bezieht sich auf Früheres und die Gleichsetzung des Gegenteils von einfach mit rechenintensiv, obwohl eine AGGREGAT-Fml ja nun auch nicht gerade einfach ist, WFs Fml schon, aber eben begrenzt, die Verwendung von ADRESSE ist besser, was ich ursprünglich beachtet hatte, in der hier dargestellten Fml aber leider nicht (sie sollte kurz sein u.der von WF nahe­kommen → dabei ist das dann unter­gegangen; HptZiel war ohnehin, darzu­stellen, welcher Fkt die MxFmlForm geschuldet ist!). Damit wäre sie dann länger als die von Sepp, aber darauf kommt's ja wie gesagt primär nicht an…
Eine Fml muss nicht immer universell, sondern kann auch auf das spezielle Problem zugeschnitten sein, denn eine Fml ist wie ein Baukasten, ändern sich die Voraus­setzungen der Aufgabe, müssen neue „Klötzer“ her. Man kann aber natürlich auch von vorn­herein derartige Änderungen berück­sichtigen. Im Ggsatz dazu, sollte eine Fkt schon möglichst universell im Rahmen ihrer Aufgabe sein, denn sie sollte ja vielen Ausgangs­Situationen rechnung tragen. Ob dann immer gleich eine „SuperFkt“ benutzt wdn sollte, wenn's auch anders geht, steht dahin…
4. „Reine“ Fml-Freaks würde ich bspw eher auf dich, WF und Shift-Del (Detlef) beziehen. Bei Sepp B. bin ich mir nicht sicher, ob er nicht noch andere Xl-Stärken/-Interessen hat (der andere Sepp, wohl der zurückgekehrte J.E., mit Sicherheit), deshalb habe ich auch mehr oder weniger geschrieben…
Sofern Fktt durch arithmetische Berechnungen ersetzt wdn können, dürfte das tatsächlich günstiger sein, nur wird so etwas dann oft schlechter verstanden. Ich mache das auch oft in UDFs, aber deren Pgm muss ja keiner verstehen, nur sie anwenden… ;-)
5. Meine UDFs sind durchaus nicht „immer und überall“ das geeignetere Mittel, aber das ist bei Standard-Xl-Fktt auch so. Sie sind es aber genau dann, wenn eine entsprechende oder wenigstens ähnliche Fktio­nalität in Xl komplett fehlt, obwohl sie in VBA oder auch anderer vglbarer Software vorhanden ist.
6. Der Erste, der mE AGGREGAT ins Spiel gebracht hatte, war wohl Detlef im alten OL-XlFml-Forum, aber als „Euphoriker“ sehe ich tatsächlich eher dich… ;-)
Deshalb ging ich auch hier eher davon aus, dass es sich um Werbung für diese neue MultiFkt handelt, habe das aber nicht geschrieben (nebenbei, Ähnliches hatte ich schon vor Jahren und seitdem des Öfteren pgmmiert, ist nicht sonderlich schwer!).
Was (nicht nur) ich unter einer MatrixFormel verstehe, weißt du ja…
Übrigens, wenn du meinem vorherigen Link folgst, könnte einiges klarer wdn… ;-)
Na, dann weiter per aspera ad astra!
Gruß, Luc :-?


  

Betrifft: zu Deinem Angaben im angebegeben Link ... von: der neopa C
Geschrieben am: 13.07.2015 13:42:29

Hallo Luc,

... hab ich eben kurz getestet.

Ausgeblendete Zeilen werden bei mir (in XL2010) lediglich bei der Summenfunktion 109 berücksichtigt und nicht wie angegeben bei 9. Ausgeblendete Spalten werden gänzlich ignoriert.

Gruß Werner
.. , - ...


  

Betrifft: Da es m.Xl12/2007 fktt, werde ich das auch ... von: Luc:-?
Geschrieben am: 13.07.2015 20:10:15

…demnächst nochmal mit Xl14/2010 testen und das Ergebnis dann im OX/CP-Forum mitteilen, Werner;
allerdings kann ich mir kaum vorstellen, dass bzw warum das dort nicht fktionieren sollte…
Luc :-?


  

Betrifft: Es fktt erwartungsgemäß auch in Xl14/2010, ... von: Luc:-?
Geschrieben am: 14.07.2015 02:14:49

…Werner,
Ursache siehe da! ;-]
Nachtrag zum ursprünglichen Problem:
Wenn man WFs Fml wie folgt fasst; …
{=WECHSELN(ADRESSE(1;VERGLEICH(1;--ISTZAHL(A43:H43););4);1;"")}
…ist sie immer noch kürzer als Sepps, verwendet aber gleichviel Fktt (die AGGREGAT-interne 5. immer noch nicht mitgerechnet).
Meine Fml, auf der ich natürlich nicht bestehe, war ja nur ein Bsp zur MxFml-Vermeidung, könnte dann auch so lauten: =MaskOn(ADRESSE(1;VERGLEICH(Compute(RinMxList(A43:H43;-2;1));A43:H43;0);4);"gb")
Luc :-?


  

Betrifft: nochmal, ja zu Matrixfunktion(alität)sformeln ... von: der neopa C
Geschrieben am: 14.07.2015 09:43:57

Hallo Luc,

... zunächst aber der Hinweis, das Deine UDF bei mir nicht so wirkt. Dazu habe ich im dortigen thread meine Anmerkungen vorgenommen.

Und nun zu Deiner neuerlichen Aussage im hiesigen thread:

Anstelle Deiner Formelkorrektur würde: {=WECHSELN(ADRESSE(1;VERGLEICH(1;--ISTZAHL(43:43););4);1;"")} nicht nur meinen Hinweis voll berücksichtigen; dass ja auch eine 1. Zahl rechts von Z43 stehen könnte.
Vor allem wäre sie noch kürzer und ist auch voll inhaltlich wie vom Ergebnis her mit der Matrixfunktion(alität)sformel vergleichbar.

Aber ich dachte wir waren schon mal über die Sinnhaftigkeit oder Nicht- von Formellängen hinaus?

Abgesehen davon, dass Du die {} wohl nicht als Funktionalität betrachtest, stellte und stelle ich fest, dass für eine absoluten Mehrheit von Excelanwender Matrixformeln und PIVOTauswertungen noch immer ein rotes Tuch ist (wobei letzteres ja gegen die Matrixfunktionalität von der Anwendungsverständnis her ja fast ein Kinderspiel ist).

Ich jedenfalls werde weiter allen Nutzeranfragen (zu Formeln) zu den von mir als Matrixfunktion(alität)sformeln bezeichneten Lösungen raten. Auch dann, wenn wenn diese oft länger sind oder sein werden, als vergleichbare MATRIXformeln. Die Formeln sind zwar sicherlich oft nicht einfacher als MATRIXFormeln aber die ausgemachte Hemmschwelle {} entfällt.


Zur Formellänge: Kommst Du etwa auf die Idee SUMMENPRODUKT()-Formeln durch vergleichbare kürzere {SUMME()}-Formeln zu ersetzen oder SUMMEWENNS()-Formeln durch {SUMME(WENN())}-Formeln?

Um hier nicht missverstanden zu werden, natürlich weiß ich, dass zumindest einige {SUMME()}-Formeln nicht durch SUMMENPRODUKT()-Formeln und {SUMME(WENN())}-Formeln nicht durch SUMMEWENN() ersetzt werden können. Das ist aber kein Grund derartige Funktionen zu negieren oder gegen sie zu argumentieren.

Für mich jedenfalls sind und bleiben Matrixfunktion(alität)sformeln (natürlich nur da, wo die Voraussetzung durch Vorhandensein einer entsprechender Excelversion gegeben ist) die einfachere und damit auch bessere Alternative für die mE klar überwiegende Zahl der normalen Excelnutzer-Anwendungsfälle. Dies natürlich nur bzgl. Problemen, die über die Anwendungen einfacher Standardfunktionen hinaus gehen.

Davon bin ich überzeugt und werde dies auch weiter so vertreten. Es sei denn, Du oder jemand anderes kann mir plausibel das Gegenteil nachweisen. Das dürfte aber schwer werden ;-)

Gruß Werner
.. , - ...


  

Betrifft: Ich argumentiere gg keine vorhandene Fkt, ... von: Luc:-?
Geschrieben am: 14.07.2015 13:36:08

…höchstens gg deren Pgmmierung, Werner; ;-)
aber mitunter ist es kontraproduktiv (idR bei umfangreichen Berechnungen), eine Fkt zu benutzen, die viel mehr berechnet als eigentlich nötig ist. Deine Argumentation kann sich ohnehin nur auf 1zellige MxFmln beziehen. Wenn im konkreten Fall eine andere Lösung gefun­den wdn kann, die dann auch nicht aufwendiger ist, warum nicht!
Was die MxFml-Verständnis-Problematik betrifft, glaube ich nicht, dass die Übertragung von spezifischen Eigenschaften einer Fkt, die letztlich ihrer Pgmmierung geschuldet sind, auf eine ganze Fml, wirklich zum besseren Verständnis von MxFmln beiträgt, denn sie macht das Ganze für den NormalNutzer eher noch mysteriöser.
Bei meiner Ergänzung von WFs Fml ging's mir nicht in 1.Linie um Kürze, sondern um einfache Durch­schaubarkeit. Der neue Rahmen war ja auch bei Sepps AGGREGAT-Fml erforderlich. Natürlich ist es legitim, so vorzugehen, aber man muss ja nicht unbedingt „mit einem Mikroskop Nägel einschlagen“, wenn auch ein Hammer zur Hand ist… ;-)
Und das AGGREGAT kein „AllzweckWerkzeug“ ist, hattest du ja auch schon festgestellt…
Im Übrigen glaube ich nicht, dass die o.g. UDF bei dir nicht so fktt, wie von mir beschrieben. Ich habe das dort dargelegt. Hier im Thread habe ich sie auch nur erwähnt, weil an ihr gut zu erkennen ist, wie das zustande kommen kann, was du Matrix­(formel­)Funktio­nalität nennst… ;-)
Gruß, Luc :-?


  

Betrifft: Zahl suchen VBA von: Sepp
Geschrieben am: 09.07.2015 22:14:39

Hallo Ben,

sicher geht das per VBA, aber beschreibe zuerst, was du genau erreichen willst, da steckt doch sicher mehr dahinter.

Gruß Sepp



  

Betrifft: AW: Zahl suchen VBA von: Ben
Geschrieben am: 09.07.2015 22:28:15

Es geht darum, dass ich meine Mitarbeiter automatisch mit einem k hinterlegen möchte von Datum bis Datum. Das habe ich soweit fertig. Jetzt soll es aber so sein, dass an dem Tag nach der Krankheit, an dem der Mitarbeiter den ersten Tag wieder arbeiten kommen würde, ein ? hinterlegt werden soll. Daher suche ich die erste Zelle nach einer Variablen Range wo eine Stundenanzahl vorkommt.

Bsp.

Mitarbeiter x meldet sich vom 01.07. (Mittwoch) bis 04.07. (Samstag) krank. Das System hinterlegt nun an den Tagen an dem der Mitarbeiter arbeiten würde automatisch ein "k". Sein nächster Arbeitstag wäre jetzt der 07.07. (Dienstag), weil er am Montag frei hat. Nun möchte ich, dass das System erkennt, dass der Mitarbeiter erst am Dienstag kommt und dort ein "?" hinterlegt.

Versteht ihr was ich meine? :)


  

Betrifft: und wozu brauchst du dafür .... von: Sepp
Geschrieben am: 09.07.2015 22:31:16

die Spaltenbezeichnung?



Gruß Sepp



  

Betrifft: AW: und wozu brauchst du dafür .... von: Ben
Geschrieben am: 09.07.2015 22:41:49

Um zu sehen in welcher Spalte die nächste Zahl steht und um dann dort das Fragezeichen zu setzen. Es geht auch sicher anders aber deswegen frage ich ja :)


  

Betrifft: AW: und wozu brauchst du dafür .... von: Sepp
Geschrieben am: 09.07.2015 22:50:53

Hallo Ben,

lade eine Beispieldatei mit Beschreibung hoch.

Gruß Sepp



 

Beiträge aus den Excel-Beispielen zum Thema "Nächste Zelle mit Zahl in einer Zeile suchen"