C# Problemas con un tipo de guardado

[TickTack]

Hola,

estaba con reproductor mp3. Tiene un boton con el siguiente codigo bajo el evento del click:

Código (csharp) [Seleccionar] Expandir


OpenFileDialog abrir = new OpenFileDialog();

           if (openFileDialog1.ShowDialog() == System.Windows.Forms.DialogResult.OK)
           {
               f = openFileDialog1.SafeFileNames;
               p = openFileDialog1.FileNames;


               for (int i = 0; i < f.Length; i++)
               {

                   listBox1.Items.Add(f[i]);
                   
               }

               foreach (string s in abrir.FileNames)
               {
                   listBox1.Items.Add(s);


               }

           }


Código [Seleccionar] Expandir


axWindowsMediaPlayer1.URL = p[listBox1.SelectedIndex];


Bueno aqui se reproduce la cancion del indice seleccionado.

Bueno, al abrir la primera vez varios archivos de una vez todo va muy bien.

Al hacerlo por segunda vez tambien. Pero me larga error al reproducir.

Es que el for sobreescribe los indices. Hay alguna manera de solucionar esto?


Gracias y saludos

[Eleкtro]

me larga error al reproducir.

Por favor, si formulas una pregunta sobre un error en programación, menciona el mensaje de error. No somos adivinos...

Es que el for sobreescribe los indices. Hay alguna manera de solucionar esto?

No sé muy bien cual es el propósito real que quieres conseguir en el código que has mostrado, ya que por un lado se puede ver que declaras un OpenFileDialog con nombre "abrir", el cual no usas para nada en esa unidad de código, y sin embargo luego intentas acceder a su propiedad "abrir.FileNames" sin haber seleccionado ningún archivo mediante ese objeto "abrir", por que en su lugar lo que haces es usar otro objeto llamado "openFileDialog1", y en el ListBox solamente estás añadiendo el nombre y extensión del archivo (OpenFileDialog.SafeFileNames), sin la ruta de directorio.

En fin, a simple vista a mi me da la sensación de que ese código simplemente es un cúmulo de cosas desordenadas que te han provocado confusión y cometer un error bobo, deberias depurarlo un rato para que tu mismo veas y entiendas qué y cómo lo estás llevando todo a cabo...

Creo que esto es lo que realmente quieres hacer:

Código (csharp) [Seleccionar] Expandir

using (OpenFileDialog ofd = new OpenFileDialog { Multiselect = true }) {

if (ofd.ShowDialog() == DialogResult.OK) {
   ListBox1.BeginUpdate();
   ListBox1.Items.Clear();
   ListBox1.Items.AddRange(ofd.FileNames);
   ListBox1.EndUpdate();
}
}

Saludos!

[TickTack]

Hola Elektro,

Por favor, si formulas una pregunta sobre un error en programación, menciona el mensaje de error. No somos adivinos...

Bueno. Pues como eres tan inteligente y verdadaremente nunca vi alguien tan inteligente en C# como tu, crei que desarollaste la capacidad de adivinar todos los errores de Visual Studio con solo leer el codigo. (Una broma).

Bueno a tu codigo le agregue esto y te queria mostrarlo:

Código (csharp) [Seleccionar] Expandir


using (OpenFileDialog ofd = new OpenFileDialog { Multiselect = true })
           {

               if (ofd.ShowDialog() == DialogResult.OK)
               {
                   listBox1.BeginUpdate();
                   listBox1.Items.Clear();
                   listBox1.Items.AddRange(ofd.FileNames);
                   listBox1.EndUpdate();
               }

               f = ofd.SafeFileNames;
               p = ofd.FileNames;


               for (int i = 0; i < f.Length; i++)
               {

                   listBox1.Items.Add(f[i]);
               }

               foreach (string s in ofd.FileNames)
               {
                   listBox1.Items.Add(s);


               }
           }


Al probar el programa pasa esto: Elijo dos canciones. Cuando le doy Ok al FileDialog, en el listBox me sale primero las rutas de esas dos canciones, luego los nombres, y luego otra vez las rutas.

Esperaba que solo salieran los nombres.

Yo lo que queria hacer era recoger las rutas y los nombres con el OpenFileDialog. Y cada vez que le doy al boton abrir, que esas canciones junto con sus rutas se amonten al final de la lista del listBox.

Voy en mal camino?

Gracias y saludos

[Eleкtro]

Esperaba que solo salieran los nombres.

Yo lo que queria hacer era recoger las rutas y los nombres con el OpenFileDialog. Y cada vez que le doy al boton abrir, que esas canciones junto con sus rutas se amonten al final de la lista del listBox.

Voy en mal camino?

Si no entiendo mal, ¿estás diciendo que quieres hacer algo así?:



Eso a simple vista carece de sentido, aparte de ser muy poco práctico, poco amistoso. El concepto de ListBox es representar una secuencia de elementos... de un Array unidimensional (ej. un Array de String, o un Array de Imágenes...aunque esto último requiere algo más de trabajo), pero tu tienes dos elementos (nombre de archivo, y ruta absoluta del archivo) por ende sería más apropiado usar un control con rejilla como un ListView o DataGridView para representar la información en filas y columnas....



...O bien si lo prefieres puedes seguir usando un ListBox y usar un tipo específico (en este ejemplo de aquí abajo un diccionario, pero puedes usar el tipo que prefieras) para "recojer" el nombre del archivo y la ruta absoluta, ambos datos (es decir, una colección de Arrays), pero representar solamente uno de esos dos elementos en el ListBox:

Código (csharp) [Seleccionar] Expandir

Dictionary<string, string> fileDict = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);

using (OpenFileDialog ofd = new OpenFileDialog { Multiselect = true }) {

   if (ofd.ShowDialog() == DialogResult.OK) {
       for (int x = 0; x <= (ofd.FileNames.Count() - 1); x++) {
           if (!fileDict.ContainsKey(ofd.FileNames[x])) {
               fileDict.Add(ofd.FileNames[x], ofd.SafeFileNames[x]);
           }
       }
       listBox1.BeginUpdate();
       listBox1.Items.AddRange(fileDict.Values.ToArray());
       listBox1.EndUpdate();
   }

}
...Luego sencillamente te encargarías de controlar el evento ListBox.SelectedIndexChanged para obtener el valor (la ruta absoluta, o el nombre del archivo) del objeto (fileDict) que recojió ambos datos, y hacer lo que desees con esa información...

Saludos

[Serapis]

Bueno a tu codigo le agregue esto y te queria mostrarlo:
....
Al probar el programa pasa esto: Elijo dos canciones. Cuando le doy Ok al FileDialog, en el listBox me sale primero las rutas de esas dos canciones, luego los nombres, y luego otra vez las rutas.
....
Esperaba que solo salieran los nombres.

A Elektro, le ha faltado responderte a esto...
Tu licencia al añadir código, demuestra que no entiendes lo que lees, ni lo que hace el código...

Esto:

Código [Seleccionar] Expandir

listBox1.Items.AddRange(ofd.FileNames);
             
Viene a ser equivalente a esto:                

Código [Seleccionar] Expandir

foreach (string s in ofd.FileNames)
    {
     listBox1.Items.Add(s);
     }
Pero en una sola línea de código... Add, añade UN SOLO ítem cada vez, Addrange, añade TODOS LOS items de una vez, de una colección.
Y en resumen estás repitiendo la misma operación, dos veces, luego es normal que te salga repetido... Esto te ocurre porque no entiendes el código que te ha puesto, pero no solo no lo entiendes al leerlo, es que ni has buscado info si desconoces los métodos, ni tan siquiera has probado su código 'suelto' sin ningún añadido, para al menos '...ver que hace...', y si no lo logras deducir, ampliar luego la información...

----------------------
Por otro lado, también está mal que haces eso fuera de la comprobación del "showdialog = OK", es decir tu te empeñas en añadir ítems incluso si el usuario canceló ... entonces para que hacer una comprobación, y si no es ok, podría dar error al tratar de acceder a una carpeta para la que se ha cancelado comprobaciones internas....

Yo lo que queria hacer era recoger las rutas y los nombres con el OpenFileDialog. Y cada vez que le doy al boton abrir, que esas canciones junto con sus rutas se amonten al final de la lista del listBox.

Aquí elektro, ha tirado por el atajo, mostrándote opciones para cada caso.
Yo te pregunto, es realmente necesario recoger las rutas de cada fichero?. No, no respondas, ya te respondo yo: Sólo si los ficheros a añadir al listbox, puedne proceder de diferentes carpetas de origen, si todas proceden de la misma y única carpeta, basta asociar una variable con el listbox,

Código [Seleccionar] Expandir

listbox Mp3FilesLsbox <---- tu listbox, podría llamarse así, en vez de un genérico listbox1.
//aunque suele acosejarse poner el nombre del objeto delante, a veces si hay más objetos relacioneados entre sí, conviene ponerlo al final, y así todos los que están relacionados comiencen por las mismas letras (el intellisense, los mostrará todos juntos, mucho más cómodo, claro y rápido que todos separados)
string Mp3Folder <---- y la carpeta común a todos esos ficheros del listbox, podría llamarse así.
//la ruta completa sería entonces una concatenación de mp3folder + mp3fileslsbox.item(k) ----> teniendo en cuenta que la ruta de la carpeta ya acabe en  "\"

Si tu listbox, ha de acoger ficheros de diferentes carpetas, entonces si resulta necesario mantener la carpeta asociada con cada fichero individual. Todavía queda la pregunta... ¿y es necesario presentarla en ese caso al usuario?. Seguramente sí, si dos ficheros pueden tener el mismo nombre, por que si no, no sabría a cuál se refiere. Incluso así, se podría añadir bajo (o encima) del listbox una caja de texto, tal que cuando el usuario pulse un ítem (el cual muestre el fichero), dicha caja se actualice con la ruta de dicho fichero. Es una alternativa más que Elektro no te ha señalado. Sin embargo, al contener dos datos para un solo elemento, necesitas un contenedor interno de más de un elemento... desde un array con dos dimensiones a un diccionario, tabla hash, pasando por un array con una dimensión pero alojando en cada elemento una estructura, por ejemplo:

Código [Seleccionar] Expandir

Structure FullPathMp3
    String File             <------- nombre del fichero
    String Folder         <------- Carpeta
    //Buleno Selected  <------- en multiselección, está seleccionado?
    //Entero IndexRepro  <----- Si el orden de reproducción no es el que aparece en el listbox
end Structure

Array of FullPathMp3 Mp3Files

En definitiva internamente necesitas algún tipo de colección, incluso una clase específica, que sería lo más coherente, que al tiempo alojara métodos adecuados a la finalidad perseguida.

Nota que es preciso entender, diferenciar y separar la organización interna de los datos de la organización mostrada al usuario (grásfica), una no tiene que ser un reflejo exacto de la otra. Internamente puedes tener un array de estructuras con dos ítems (nombre y carpeta) y gráficamente puedes tener un grid de dos columnas, o un listbox y debajo una caja de texto, como ya te comentaba con anterioridad.

antes de iniciar un proyecto, uno debe hacer un boceto a lápiz de como quiere que reflejar la interfaz al usuario (más oomenos, luego puede sufrir algún cambio), pero eso te ayuda a saber que tipo de objetos vas a anecesitar para implementarlo... ir haciendo las cosas sobre la marcha, es tropezar en muchos problemas, y esto solo es asequible cuando lleves muchos años programando, hasta entonces siempre haz un boceto a lápiz... ubica los controles que ha de tener el usuario, define el menú, etc... es el punto de partida adecuado...

Voy en mal camino?

Creo que ya tienes respondido esto... pero especifico...

Es mal camino, si vas decidiendo cosas sobre la marcha, es mal camino, si ignoras el código que te dan, tu lo copias, lo pegas y luego debajo pegas lo tuyo previo, sin siquiera pararte a pensar qué hace ese código que te dieron, es mal camino, si no te has planteado previamente si es necesario que el usuario tenga vista del nombre del fichero sólo o si también de la ruta y en ese caso, si es necesario para cada fichero o solo para el actualmente seleccionado, si el usuario puede cargar ficheros al listbox de diferentes carpetas, osi tras elegir cargar de una carpeta se borra previamente el contenido del listbox... es mal camino, si no haces previamente un boceto 8como mínimo), para poder seguir un orden y tener claro qué ha de hacer y qué vas a necesitar, etc...

[TickTack]

Hola Elektro,

gracias por tu aporte. Muchas gracias.

Lo mismo para NEBIRE. Tengo investigacion para esta noche.

Tu licencia al añadir código, demuestra que no entiendes lo que lees, ni lo que hace el código...

Es mal camino, si vas decidiendo cosas sobre la marcha, es mal camino, si ignoras el código que te dan, tu lo copias, lo pegas y luego debajo pegas lo tuyo previo, sin siquiera pararte a pensar qué hace ese código que te dieron, es mal camino, si no te has planteado previamente si es necesario que el usuario tenga vista del nombre del fichero sólo o si también de la ruta y en ese caso, si es necesario para cada fichero o solo para el actualmente seleccionado, si el usuario puede cargar ficheros al listbox de diferentes carpetas, osi tras elegir cargar de una carpeta se borra previamente el contenido del listbox... es mal camino, si no haces previamente un boceto 8como mínimo), para poder seguir un orden y tener claro qué ha de hacer y qué vas a necesitar, etc...

Bueno has visto que no me queda otra. Ver informacion en internet? No la entiendo. Depurar el codigo? No puedo. Aprender eso? Tampoco. Revisar las librerias de Visual Studio? No las entiendo. Dedicar horas y horas hasta que lo entienda? La eternidad no alcanzaria.

Es mi naturaleza no entender codigos. Es mi naturaleza tratar de seguir programando, sin entender  codigos. Perdon. Yo no tuve la posibilidad de hacer un curso. Tu si? Elektro?

Te limitaste bastante en hacerme criticas. Permitete hacerme mas criticas, por favor. Criticas que no sean constructivas.

En realidad no tuvieron que ayudarme. En realidad no sirve.

A veces escribo: "Alguien me ayuda?", "Por favor, necesito ayuda".
No le hagan caso a eso. Es mejor ignorar mis dudas y pedidos. Ya desde el principio.

No tendria que estar pidiendo ayuda aqui. Pero lo hago igual.

Es mi naturaleza.

[Eleкtro]

Es mi naturaleza no entender codigos. Es mi naturaleza tratar de seguir programando, sin entender  codigos. Perdon. Yo no tuve la posibilidad de hacer un curso. Tu si? Elektro?

Te limitaste bastante en hacerme criticas.

¿En realidad eso es lo que te pareció, que te hice críticas?. Dime que cosa te he criticado yo en todo el comentario que te respondí, de verdad, vuelve a leerlo, y dímelo, por que yo no consigo verlo.

Aquí estamos para intentar ayudar a los demás en su aprendizaje o a resolver problemas en sus códigos, no para criticar a nadie. Otra cosa bien distinta es que para que un programador pueda mejorar en lo que hace, hay que resaltarle los fallos que ha cometido en su código ...o las cosas que podría mejorar de éste, aunque eso tampoco sería una crítica como tal, sino una recomendación, pero claro, si a ti te da por tomártelo de forma negativa como si te estuviesen criticando, pues... macho, no era mi intención.

Es posible que el compañero @NEBIRE se haya excedido un poquito en hacer críticas, pero no me metas a mi en el mismo saco cuando sabes perfectamente que no te he criticado, y además a fin de cuentas las críticas de @NEBIRE fueron con la intención de ayudarte (y son comprensibles, por que simplemente hiciste un copy&paste del código que yo te mostré, sin saber muy bien lo que estabas haciendo, y ojo, no estoy criticando, solo estoy explicando el motivo de por qué me parece comprensiva su reacción).

Revisar las librerias de Visual Studio? No las entiendo.

En la página web de MSDN (Microsoft Developer Network), que es la referencia online oficial de la API/lirbería de clases de .NET Framework, y un lugar para el aprendizaje de todos los conceptos relacionados con la programación en general, aparte del aprendizaje completo de .NET Framework y de los lenguajes soportados por éste, pues allí te explican punto por punto el propósito/funcionalidad de cada uno de los miembros existentes en la librería de clases de .NET Framework, y en la mayoría de las ocasiones además incluyen ejemplos de código y documentados al pie de página. Por ese motivo, el echo de "no entender" no es una excusa aceptable teniendo a nuestra entera disposición una fuente de información y recursos tan amplia y detallada como la MSDN.

Te recomiendo echarle un vistazo a este comentario en donde encontrarás recursos de información para iniciarse en el aprendizaje de C# y .NET en general:

• Manuales de .NET | foro.elhacker.net

( no te pierdas tampoco los enlaces a la librería de códigos de Microsoft, donde encontrarás muchos códigos profesionales escritos en C#, que puedes analizar para aprender buenos hábitos y técnicas avanzadas de programación en general. )

Depurar el codigo? No puedo. Aprender eso? Tampoco.

¿No puedes, o no sabes, o quizás no te apetece?; en el segundo caso siempre puedes empezar a aprender... con tiempo y dedicación, y tampoco mucho empeño, no te creas, en realidad la depuración no es algo que te vaya a resultar muy complejo de entender y de efectuar... al menos de forma básica, y eso ya te será de mucha utilidad.

Me remito a las palabras que ya dije más arriba: el echo de "no poder" o no saber, no es un motivo aceptable teniendo la MSDN.

Te dejo por aquí unas guías de introducción con las que puedes aprenderlo todo lo relacionado con la depuración y el depurador de código en Visual Studio de principio a fin:

• Debugging in Visual Studio | MSDN
• Feature Tour of the Visual Studio Debugger | docs.microsoft.com

Es mi naturaleza tratar de seguir programando, sin entender  codigos.

Quizás me puedo equivocar al decirte lo siguiente, por que obviamente no te conozco ni puedo leerte el pensamiento, lo siento, pero no es una crítica:

Por todo lo que has dicho y de la manera en la que lo expresas, me transmites la sensación de que tú prefieres aprender a base de fallos, o dicho de otra manera aprender mediante el ensayo y error (o trial and error), me explico: encontrarse con un nuevo problema a resolver (ej. añadir elementos a una lista), en el que debes recurrir a la utilización de un miembro/método/concepto desconocido para ti, y al ponerlo en práctica ves que te sale mal, te da un fallo o no te da el resultado esperado, y entonces te ves en la necesidad de recurrir a la experiencia/ayuda de otras personas, entonces copias y pegas códigos esperando que eso resuelva tu problema específico, y si no lo resuelve y te da fallo entonces ponerte a buscar otro "parche" hasta poder resolverlo definitivamente, y esa no es ni de lejos una forma práctica de aprender ni de programar. Primero deberías documentarte sobre "X", comprender su propósito y todo lo que lo esté relacionado con su implementación (por ejemplo, si quisieramos documentarnos sobre el uso de la clase List, empezariamos por leer por encima las descripciones de todos los miembros/métodos públicos expuestos en dicha clase para tener una pequeña idea de qué podemos hacer con todo ello, y documentarnos más en profundidad sobre colecciones, Generics, enumeradores, y tampoco estaría de más: LINQ/LINQ to Objects), leer todo lo que haya que leer sobre él, vaya, y luego (no antes) poner en práctica lo estudiado sobre ese "X".



De verdad, no me gustaría que este tema se "cerrase" de una forma tan negativa por el tema que dijiste de las criticas, me sabe mal. @TickTack, no se muy bien si realmente debo darme aludido en el tema de criticarte, por que no me queda claro si te diriges a mi, o a @NEBIRE, o a los dos, pero bueno, no te he criticado, y lo que haya hecho o dicho @NEBIRE te lo habrá dicho con buena intención. Si tienes cualquier otra duda aquí estare(mos) para intentar ayudarte, no lo dudes.

Un saludo!

[Serapis]

A ver, yo personalmente no critico a nadie... la idea de responder es ayudar...

Igual que señalo fallos en el código, señalo fallos en el programador. Pero porque a veces el fallo está en el código y a veces el fallo está en el programador.

Si Elektro te puso el código que cumple tus necesidades y tu luego copias y pegas y añades código superfluo, ahora demuestras que el fallo está en el programador, luego señalo el fallo encontrado...

Si el fallo está en el código, pués señalo por donde puedes avanzar, con código y más a menudo con pseudocódigo. y si el fallo está en el programador, también señalo como avanzar o como evitar o solucionar el tema. De hecho mi mensaje previo está repleto de instrucciones y alternativas, que puedes seguir...

Si tú solo crees que los fallos están el código y que tu no debes 'corregirte' entonces seguirás siempre en la 'oscuridad' sin aprender nada, si no tras tropecientos mil intentos...

No te lo tomes a mal, nadie está aquí para molestar, aprende y sigue adelante...

[TickTack]

Hola Elektro,

tu no me hiciste criticas. Me referia a NEBIRE. Y que lo hiciera, eso no lo critique. Al
contrario. No se si leiste, pero escribi: "Permitete hacerme mas criticas, por favor.
Criticas que no sean constructivas."

Y con el tema de Visual Studio y que yo no soy ni sere nunca competente con C#, las librerias
de Visual Studio ni que mi torpez jamas se cambiara tengo esto que decir:

Yo te ensenere:

No entiendo lo que significa la clase Dictionary<TKey, TValue>. Bueno, busquemos en
microsoft.com. Ahi leemos: Representa una colección de claves y valores. Excelente!
Entiendo! Sigamos: Jerarquía de herencia:
System.Object
   System.Collections.Generic.Dictionary<TKey, TValue>
       System.ServiceModel.MessageQuerySet

Aha. Interesante. Sigamos:
Sintaxis:
[SerializableAttribute]
[ComVisibleAttribute(false)]
public class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>,
   ICollection<KeyValuePair<TKey, TValue>>, IEnumerable<KeyValuePair<TKey, TValue>>,
   IEnumerable, IDictionary, ICollection, IReadOnlyDictionary<TKey, TValue>,
   IReadOnlyCollection<KeyValuePair<TKey, TValue>>, ISerializable,
   IDeserializationCallback

Mometo! Que es [SerializableAttribute]? Busquemos en microsoft.com de nuevo. Ahi encontramos:
Indica que una clase se puede serializar. Esta clase no puede heredarse.

Espera... que significa serializar en C#? Busquemos en Wikipedia Serializacion.
Ahi leemos: En ciencias de la computación, la serialización (o marshalling en inglés)
consiste en un proceso de codificación de un objeto en un medio de almacenamiento (como
puede ser un archivo, o un buffer de memoria) con el fin de transmitirlo...
Pero... espera de nuevo. Que es un buffer?

Busquemos de nuevo en Wikipedia. En Búfer de datos leemos: En informática, un búfer (del
inglés, buffer) es un espacio de memoria, en el que se almacenan datos de manera temporal,
normalmente para un único uso (generalmente utilizan un sistema de cola FIFO); su principal
uso...
Un momento... Que era el sistema de cola FIFO? Tengo que verlo...

Y asi podria estar dias, semanas, meses, anos, decadas....

Tu quiza no. NEBIRE tampoco. Tendran otra mente. Con intelegencia normal. O tuvieron un
curso y todas esa palabras les fueron ensenadas.

Pero yo no.

Por todo lo que has dicho y de la manera en la que lo expresas, me transmites la sensación
de que tú prefieres aprender a base de fallos, o dicho de otra manera aprender mediante el
ensayo y error (o trial and error), me explico: encontrarse con un nuevo problema a resolver
(ej. añadir elementos a una lista), en el que debes recurrir a la utilización de un
miembro/método/concepto desconocido para ti, y al ponerlo en práctica ves que te sale mal,
te da un fallo o no te da el resultado esperado, y entonces te ves en la necesidad de
recurrir a la experiencia/ayuda de otras personas, entonces copias y pegas códigos esperando
que eso resuelva tu problema específico, y si no lo resuelve y te da fallo entonces ponerte
a buscar otro "parche" hasta poder resolverlo definitivamente, y esa no es ni de lejos una
forma práctica de aprender ni de programar.

Exacto! Pero no me queda otra. Les dije que ustedes no tienen porque ayudarme. ES EN VANO.
Ni siquiera soy capaz de hacer un madito reproductor mp3.

Hola NEBIRE,

claro que el fallo esta mi. De esto no hay duda.

A ver, yo personalmente no critico a nadie...

Por supuesto que lo haces. Para ti es ayuda en vez de critica. Pero no digo que esta mal que
me critiques. Digo que deberias hacerme mas criticas que no sean constructivas en vez de
mostrarme codigos. Asi como lo hiciste en este ultimo comentario tuyo pero todavia faltan
mas criticas...

Saludos

[Serapis]

No entiendo nada.
Si quieres programar, y dedicarte a esto, lo primero e imprescindible es aprender lo básico y elemental, al margen de cualquier lenguaje de programación.

Tienes que saber operar con números, tienes que entender los números negativos y las bases binaria, hexadeciaml y octal (la decimal se supone que uno lo tiene).
Tienes que saber que son las operaciones lógicas, aritméticas, qué son los condicionales y las bifurcaciones, que son las funciones, propiedades, variables, secciones de código...
Tienes que saber la diferencia entre la ejecución compilada e interpretada y por lo mismo que es depurar/'debugar' un programa.
Tienes que conocer las estructuras básicas de datos: array, estructuras, listas enlazadas, pilas (FIFO), colas (LIFO), árboles, ficheros y de las bases de datos al menos algo somero...

...y todo sin profundizar, lo básico al menos. Solo entonces es cuando puedes decantarte por un lenguaje y avanzar en profundidad, si todo lo básico lo conoces, nada en un lenguaje va a ser tan complejo que te resulte incomprensible.

Sin un conocimiento básico, es perder el tiempo. Es como querer arreglar un avión cuando no conoces ni como funciona una bicicleta.

Es impòsible poder prestar ayuda útil a alguien que carece de conocimientos básicos... ¿qué baldosa puedo decirte que pises si tu no la conoces y yo ignoro lo que tu desconoces?. Cuando alguien se pone a programar se le supone que sabe lo básico y si no es así, su prioridad no debe ser otra que adquirir esa base... se torna absurdo querer conbstruir un avión, cuando uno no sabe lo que es un ala, ni un motor a reacción ni siquiera un tobera de escape, ni una hélice. ¿¿¿Cómo se supone que vas a hacer algo que no sabes ni cómo es, ni de qué piezas se compone????.